Le 04/09/2023 à 16:48, Christophe Leroy a écrit : > > > Le 03/09/2023 à 23:06, Erhard Furtner a écrit : >> On Fri, 1 Sep 2023 07:43:34 +0000 >> Christophe Leroy <christophe.le...@csgroup.eu> wrote: >> >>>>> Can you try what happens when you remove the call to kasan_init() >>>>> at the >>>>> start of setup_arch() in arch/powerpc/kernel/setup-common.c >>>> >>>> Ok, so I left the other patches in place + btext_map() instead of >>>> btext_unmap() at the end of MMU_init() + Michaels patch and >>>> additionally commented-out kasan_init() as stated above. The outcome >>>> is rather interesting! Now I deterministically get this output at >>>> boot OF console, regardless wheter it's a cold boot or warm boot: >>> >>> Ah, my bad. You also need to remove the call to kasan_late_init() in >>> mem_init() in arch/powerpc/mm/mem.c >> >> Not tragic. Meanwhile I commented-out kasan_late_init() and updated to >> kernel v6.5.1. >> >> dmesg did not change however, getting the same "BUG: KASAN: >> stack-out-of-bounds in __kernel_poison_pages+0x6c/0xd0" as last time >> only on v6.5.1. >> > > > Ok, so lets come back to normal situation. Can you add back kasan_init() > and kasan_late_init(), while keeping the btext changes and Michael's patch. > > Then see what result you get with CONFIG_KASAN but without > CONFIG_KASAN_VMALLOC > > It would help narrow the problem area because kasan_init() does several > things based on CONFIG_KASAN_VMALLOC. >
Another thing that could be interesting to test is to remove (or comment out) the following line in arch/powerpc/mm/kasan/Makefile : obj-$(CONFIG_PPC_BOOK3S_32) += book3s_32.o That way, the weak version of kasan_init_region() will be used instead of the one in book3s_32.c
