From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Liu Shixin <liushixin2@huawei.com>,
Marco Elver <elver@google.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc: don't select KFENCE on platform PPC_FSL_BOOK3E
Date: Fri, 24 Sep 2021 08:41:57 +0200 [thread overview]
Message-ID: <f8d12860-56d7-5697-7cba-3cac95bb0a1c@csgroup.eu> (raw)
In-Reply-To: <20210924063927.1341241-1-liushixin2@huawei.com>
Le 24/09/2021 à 08:39, Liu Shixin a écrit :
> On platform PPC_FSL_BOOK3E, all lowmem is managed by tlbcam. That means
> we didn't really map the kfence pool with page granularity. Therefore,
> if KFENCE is enabled, the system will hit the following panic:
Could you please explain a bit more what the problem is ?
KFENCE has been implemented with the same logic as DEBUG_PAGEALLOC.
DEBUG_PAGEALLOC is enabled on FSL_BOOK3E.
In MMU_setup(), __map_without_ltlbs is set to 1 when KFENCE is enabled.
__map_without_ltlbs should disable the use of tlbcam.
So what's wrong really ?
Does DEBUG_PAGEALLOC work on FSL_BOOK3E ?
Thanks
Christophe
>
> BUG: Kernel NULL pointer dereference on read at 0x00000000
> Faulting instruction address: 0xc01de598
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K SMP NR_CPUS=4 MPC8544 DS
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc3+ #298
> NIP: c01de598 LR: c08ae9c4 CTR: 00000000
> REGS: c0b4bea0 TRAP: 0300 Not tainted (5.12.0-rc3+)
> MSR: 00021000 <CE,ME> CR: 24000228 XER: 20000000
> DEAR: 00000000 ESR: 00000000
> GPR00: c08ae9c4 c0b4bf60 c0ad64e0 ef720000 00021000 00000000 00000000 00000200
> GPR08: c0ad5000 00000000 00000000 00000004 00000000 008fbb30 00000000 00000000
> GPR16: 00000000 00000000 00000000 00000000 c0000000 00000000 00000000 00000000
> GPR24: c08ca004 c08ca004 c0b6a0e0 c0b60000 c0b58f00 c0850000 c08ca000 ef720000
> NIP [c01de598] kfence_protect+0x44/0x6c
> LR [c08ae9c4] kfence_init+0xfc/0x2a4
> Call Trace:
> [c0b4bf60] [efffe160] 0xefffe160 (unreliable)
> [c0b4bf70] [c08ae9c4] kfence_init+0xfc/0x2a4
> [c0b4bfb0] [c0894d3c] start_kernel+0x3bc/0x574
> [c0b4bff0] [c0000470] set_ivor+0x14c/0x188
> Instruction dump:
> 7c0802a6 8109d594 546a653a 90010014 54630026 39200000 7d48502e 2c0a0000
> 41820010 554a0026 5469b53a 7d295214 <81490000> 38831000 554a003c 91490000
> random: get_random_bytes called from print_oops_end_marker+0x40/0x78 with crng_init=0
> ---[ end trace 0000000000000000 ]---
>
> Signed-off-by: Liu Shixin <liushixin2@huawei.com>
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d46db0bfb998..cffd57bcb5e4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -185,7 +185,7 @@ config PPC
> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
> select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
> select HAVE_ARCH_KGDB
> - select HAVE_ARCH_KFENCE if PPC32
> + select HAVE_ARCH_KFENCE if PPC32 && !PPC_FSL_BOOK3E
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> select HAVE_ARCH_NVRAM_OPS
>
next prev parent reply other threads:[~2021-09-24 6:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 6:39 Liu Shixin
2021-09-24 6:41 ` Christophe Leroy [this message]
2021-09-25 3:10 ` Liu Shixin
2021-09-28 3:06 ` Liu Shixin
2021-10-12 1:43 ` Liu Shixin
2021-10-12 5:41 ` LEROY Christophe
2021-10-12 6:24 ` Michael Ellerman
2021-10-12 17:28 ` Christophe Leroy
2021-10-13 0:48 ` Michael Ellerman
2021-10-13 8:16 ` 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=f8d12860-56d7-5697-7cba-3cac95bb0a1c@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=benh@kernel.crashing.org \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=liushixin2@huawei.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®