All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH] powerpc/kasan/book3s_64: warn when running with hash MMU
Date: Mon, 10 Oct 2022 09:10:37 -0500	[thread overview]
Message-ID: <8735bvbwgy.fsf@linux.ibm.com> (raw)
In-Reply-To: <87h70for01.fsf@mpe.ellerman.id.au>

Michael Ellerman <mpe@ellerman.id.au> writes:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> + KASAN list
>>
>> Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
>>> Nathan Lynch <nathanl@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).

This avoids the boot-time oops, but kasan remains unimplemented for hash
mmu. Raising the question: with the trivial crashes addressed, is the
current message ('KASAN not enabled as it requires radix!') sufficient
to notify developers (such as me, a week ago) who mean to use kasan on a
book3s platform, unaware that it's radix-only? Would a WARN or something
more prominent still be justified?

I guess people will figure it out as soon as they think to search the
kernel log for 'KASAN'...

  reply	other threads:[~2022-10-10 14:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04 22:37 [PATCH] powerpc/kasan/book3s_64: warn when running with hash MMU Nathan Lynch
2022-10-06  4:10 ` Michael Ellerman
2022-10-06  5:04   ` Christophe Leroy
2022-10-07 10:41     ` Michael Ellerman
2022-10-10 14:10       ` Nathan Lynch [this message]
2022-10-10 17:03         ` Christophe Leroy
2022-10-11 10:00         ` Michael Ellerman
2022-10-11 10:25           ` Christophe Leroy
2023-01-26  7:11             ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735bvbwgy.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.