Le 11/10/2022 à 12:00, Michael Ellerman a écrit :

Nathan Lynch [off-list ref] writes:

quoted

Michael Ellerman [off-list ref] writes:

quoted

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).

It works but I still see the kasan shadow getting mapped, which we would
ideally avoid.

 From PTDUMP:

---[ kasan shadow mem start ]---
0xc00f000000000000-0xc00f00000006ffff  0x00000000045e0000       448K         r  w       pte  valid  present        dirty  accessed
0xc00f3ffffffe0000-0xc00f3fffffffffff  0x0000000004d80000       128K         r  w       pte  valid  present        dirty  accessed

I haven't worked out how those are getting mapped.

kasan_populate_vmalloc() maybe ?

Christophe