[PATCH] mm,kfence: decouple kfence from page granularity mapping judgement

[Zhenhua Huang]

On 2023/3/9 19:38, Marco Elver wrote:
> On Thu, 9 Mar 2023 at 12:26, Zhenhua Huang <quic_zhenhuah at quicinc.com> wrote:
> [...]
>>> Ah right - well, you can initialize __kfence_pool however you like
>>> within arm64 init code. Just teaching kfence_alloc_pool() to do
>>> nothing if it's already initialized should be enough. Within
>>> arch/arm64/mm/mmu.c it might be nice to factor out some bits into a
>>> helper like arm64_kfence_alloc_pool(), but would just stick to
>>> whatever is simplest.
>>
>> Many thanks Marco. Let me conclude as following:
>> 1. put arm64_kfence_alloc_pool() within arch/arm64/mm/mmu.c as it's
>> arch_ specific codes.
>> 2. leave kfence_set_pool() to set _kfence_pool within kfence driver, as
>> it may become common part.
>>
>> The reason we still need #2 is because _kfence_pool only can be used
>> after mapping set up, it must be late than pool allocation. Do you have
>> any further suggestion?
> 
> I don't mind kfence_set_pool() if it helps avoid some #ifdef CONFIG_KFENCE.
> 
> However, do note that __kfence_pool is exported from
> include/linux/kfence.h. Since you guard all the new arm64 code by
> #ifdef CONFIG_KFENCE, kfence_set_pool() doesn't look necessary.
> However, if you do something like:
> 
> #ifdef CONFIG_KFENCE
> ... define arm64_kfence_alloc_pool ...
> #else
> ... define empty arm64_kfence_alloc_pool that returns NULL ...
> #endif
> 
> and make that the only #ifdef CONFIG_KFENCE in the new arm64 code,
> then you need kfence_set_pool(). I think that'd be preferable, so that
> most code is always compile-tested, even if the compiler ends up
> optimizing it out if it's dead code if !CONFIG_KFENCE.

Thanks Marco, good suggestion. I've done like this: only one 
CONFIG_KFENCE now in arch/arm64/mm/mmu.c. I also tested w/ both 
CONFIG_KFENCE and !CONFIG_KFENCE.
Please help review v2 patch :)

> 
> Thanks,
> -- Marco