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
