Thread (9 messages) 9 messages, 3 authors, 2023-01-26

Re: [PATCH] powerpc/kasan/book3s_64: warn when running with hash MMU

From: Nathan Lynch <hidden>
Date: 2022-10-10 14:11:50

Michael Ellerman [off-list ref] writes:
Christophe Leroy [off-list ref] writes:
quoted
+ KASAN list

Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
quoted
Nathan Lynch [off-list ref] writes:
quoted
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'...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help