On 2023/3/9 19:38, Marco Elver wrote:
On Thu, 9 Mar 2023 at 12:26, Zhenhua Huang <quic_zhenhuah@xxxxxxxxxxx> 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
