Michael Ellerman <m...@ellerman.id.au> writes: > Christophe Leroy <christophe.le...@csgroup.eu> writes: >> + KASAN list >> >> Le 06/10/2022 à 06:10, Michael Ellerman a écrit : >>> Nathan Lynch <nath...@linux.ibm.com> writes: >>>> kasan is known to crash at boot on book3s_64 with non-radix MMU. As >>>> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only >>>> KASAN support"): >>>> >>>> A kernel with CONFIG_KASAN=y will crash during boot on a machine >>>> using HPT translation because not all the entry points to the >>>> generic KASAN code are protected with a call to kasan_arch_is_ready(). >>> >>> I guess I thought there was some plan to fix that. >> >> I was thinking the same. >> >> Do we have a list of the said entry points to the generic code that are >> lacking a call to kasan_arch_is_ready() ? >> >> Typically, the BUG dump below shows that kasan_byte_accessible() is >> lacking the check. It should be straight forward to add >> kasan_arch_is_ready() check to kasan_byte_accessible(), shouldn't it ? > > Yes :) > > And one other spot, but the patch below boots OK for me. I'll leave it > running for a while just in case there's a path I've missed.
It works for me too, thanks (p8 pseries qemu). This avoids the boot-time oops, but kasan remains unimplemented for hash mmu. Raising the question: with the trivial crashes addressed, is the current message ('KASAN not enabled as it requires radix!') sufficient to notify developers (such as me, a week ago) who mean to use kasan on a book3s platform, unaware that it's radix-only? Would a WARN or something more prominent still be justified? I guess people will figure it out as soon as they think to search the kernel log for 'KASAN'...