Le 11/10/2022 à 12:00, Michael Ellerman a écrit :
> Nathan Lynch <nath...@linux.ibm.com> writes:
>> Michael Ellerman <m...@ellerman.id.au> writes:
>>> Christophe Leroy <christophe.le...@csgroup.eu> writes:
>>>> + KASAN list
>>>>
>>>> Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
>>>>> Nathan Lynch <nath...@linux.ibm.com> writes:
>>>>>> kasan is known to crash at boot on book3s_64 with non-radix MMU. As
>>>>>> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only
>>>>>> KASAN support"):
>>>>>>
>>>>>> A kernel with CONFIG_KASAN=y will crash during boot on a machine
>>>>>> using HPT translation because not all the entry points to the
>>>>>> generic KASAN code are protected with a call to
>>>>>> kasan_arch_is_ready().
>>>>>
>>>>> I guess I thought there was some plan to fix that.
>>>>
>>>> I was thinking the same.
>>>>
>>>> Do we have a list of the said entry points to the generic code that are
>>>> lacking a call to kasan_arch_is_ready() ?
>>>>
>>>> Typically, the BUG dump below shows that kasan_byte_accessible() is
>>>> lacking the check. It should be straight forward to add
>>>> kasan_arch_is_ready() check to kasan_byte_accessible(), shouldn't it ?
>>>
>>> Yes :)
>>>
>>> And one other spot, but the patch below boots OK for me. I'll leave it
>>> running for a while just in case there's a path I've missed.
>>
>> It works for me too, thanks (p8 pseries qemu).
>
> It works but I still see the kasan shadow getting mapped, which we would
> ideally avoid.
>
> From PTDUMP:
>
> ---[ kasan shadow mem start ]---
> 0xc00f000000000000-0xc00f00000006ffff 0x00000000045e0000 448K
> r w pte valid present dirty accessed
> 0xc00f3ffffffe0000-0xc00f3fffffffffff 0x0000000004d80000 128K
> r w pte valid present dirty accessed
>
> I haven't worked out how those are getting mapped.
kasan_populate_vmalloc() maybe ?
Christophe
