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

[Christophe Leroy]

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