Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats

Le 05/12/2021 à 22:44, Maxime Bizon a écrit :

On Sunday 05 Dec 2021 à 18:11:59 (+0000), Christophe Leroy wrote:

quoted

quoted

Is BAT5 needed here ?

Sure it is, because that's were kernel expects lowmem to be mapped.
Allthough the kernel will unlikely access the 128M reserved for KASAN
directly, the other 128M are still needed.

Yes that was my point

I'm wondering if for specific PAGE_OFFSET values, __mmu_mapin_ram()
ends using a BAT to map exactly the KASAN area, thus wasting it
because the kernel would never/rarely access it.

Is it worth it ? I have the feeling that's more a corner case.

Or worse, it could consume the latest BAT available, and there would
be none left for the actual KASAN vm area

Even more.

Maybe mmu_mapin_ram() could clamp top to KASAN phys start.

An alternative could be to try and use for KASAN some memory which is 
not available in the linear mapping.
For instance, in your case, you have move than 2G bytes mem I guess and 
you are mapping 0x00000000 to 0x5fffffff. Maybe could use 0x6000000 up 
for KASAN.

But I don't know how to proceed to do it that way. Today we use 
memblock_alloc() which is the only memory allocator available at the 
time we allocate KASAN shadow area. But memblock_alloc() allocates 
memory from the directly accessible area.

Christophe