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

[Marco Elver <elver@google.com>]

On Thu, 9 Mar 2023 at 12:26, Zhenhua Huang <quic_zhenhuah@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