KASAN debug kernel fails to boot at early stage when CONFIG_SMP=y is set (kernel 6.5-rc5, PowerMac G4 3,6)

[Erhard Furtner]

On Mon, 4 Sep 2023 14:55:17 +0000
Christophe Leroy <christophe.leroy at csgroup.eu> wrote:

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

I can't unselect KASAN_VMALLOC, it is forced on. Can only be unselected on PPC_BOOK3S_64 it seems.

 Symbol: KASAN_VMALLOC [=y]
 Type  : bool
 Defined at lib/Kconfig.kasan:179
   Prompt: Check accesses to vmalloc allocations
   Depends on: KASAN [=y] && HAVE_ARCH_KASAN_VMALLOC [=y]
   Location:
     -> Kernel hacking
       -> Memory Debugging
         -> KASAN: dynamic memory safety error detector (KASAN [=y])
           -> Check accesses to vmalloc allocations (KASAN_VMALLOC [=y])
 Selected by [y]:
   - PPC [=y] && KASAN [=y] && MODULES [=y]
 Selected by [n]:
   - PPC_BOOK3S_64 [=n] && <choice> && KASAN [=y]   && <choice> && KASAN [=y]

> 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

When I comment out this line the kernel boots fine! Even with btext_unmap() stuff back to default and using 2 CPUs again.

Regards,
Erhard