On Mon, 4 Sep 2023 14:55:17 +0000
Christophe Leroy [off-list ref] wrote:

quoted

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