[PATCH v3 4/4] ARM: Implement PAN for LPAE by TTBR0 page table walks disablement

Florian Fainelli f.fainelli at gmail.com
Mon May 13 20:56:20 PDT 2024


Hi Geert, Linus,

On 5/13/24 13:29, Linus Walleij wrote:
> On Mon, May 13, 2024 at 9:58 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>> On Mon, May 13, 2024 at 9:24 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>>> On Tue, May 7, 2024 at 3:10 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>> Thanks for your patch, which is now commit 7af5b901e84743c6 ("ARM:
>>>> 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement")
>>>> in arm/for-next (next-20240502 and later).
>>>>
>>>> On Koelsch (R-Car M2-W with dual Cortex A15) with LPAE enabled:
>>>>
>>>>      Run /sbin/init as init process
>>>>        with arguments:
>>>>          /sbin/init
>>>>        with environment:
>>>>          HOME=/
>>>>          TERM=linux
>>>>      Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
>>>>      CPU: 1 PID: 1 Comm: init Tainted: G        W        N
>>>> 6.9.0-rc1-koelsch-00004-g7af5b901e847 #1930
>>>>      Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
>>>>      Call trace:
>>>>       unwind_backtrace from show_stack+0x10/0x14
>>>>       show_stack from dump_stack_lvl+0x78/0xa8
>>>>       dump_stack_lvl from panic+0x118/0x398
>>>>       panic from do_exit+0x1ec/0x938
>>>>       do_exit from sys_exit_group+0x0/0x10
>>>>      ---[ end Kernel panic - not syncing: Attempted to kill init!
>>>> exitcode=0x00000004 ]---
>>>>
>>>> Disabling LPAE fixes the issue.
>>>
>>> How annoying. I guess it doesn't help you that it works like a charm on
>>> Versatile Express in QEMU, and also actually tested on the real
>>> hardware. (Dual Cortex-A9).
>>
>> Interesting. AFAIK Cortex-A9 does not support LPAE?
> 
> Allright I was rambling, what I used (albeit early on) was
> STMicro STM32MP157 which has Cortex-A7.
> 
>>> So init is not executing, which userspace is this? I was  just testing
>>> with busybox so far, maybe I need to test on something
>>> bigger?
>>>
>>> Do you have your ARMv7 file system available in an image or so
>>> I can test it on Versatile Express?
>>
>> It's just a Debian nfsroot.
> 
> OK I tried with a vanilla ArchLinuxARM rootfs which uses systemd
> and all that hoopla and it boots just fine.
> 
> So I'm a bit lost here.
> 
> I guess I should bring out the STM32MP157 board again and retest
> to verify that that one hardware works with this. Any other ideas?

FWIW, my ARCH_BRCMSTB systems using Brahma-B15, Brahma-B53 and 
Cortex-A72 CPUs are all happily booting the kernel to users-space with 
linux-next/master and CONFIG_CPU_TTBR0_PAN=y.

However I am not able to get my Raspberry Pi 4B to boot 
linux-next/master with CONFIG_CPU_TTBR0_PAN=y, too.

Error is similar to Geert, see below.

[   11.299106] Freeing unused kernel image (initmem) memory: 79872K
[   11.305720] Run /init as init process
[   11.314070] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x00000004
[   11.321888] CPU: 0 PID: 1 Comm: init Not tainted 6.9.0-next-20240513 #32
[   11.328709] Hardware name: BCM2711
[   11.332169] Call trace:
[   11.332179]  unwind_backtrace from show_stack+0x10/0x14
[   11.340087]  show_stack from panic+0x20c/0x55c
[   11.344615]  panic from do_exit+0x6b0/0x1e74
[   11.348972]  do_exit from do_group_exit+0xcc/0x280
[   11.353857]  do_group_exit from get_signal+0xfb4/0x1340
[   11.359182]  get_signal from do_work_pending+0x2c0/0x7bc
[   11.364590]  do_work_pending from slow_work_pending+0xc/0x24
[   11.370351] Exception stack(0xf082bfb0 to 0xf082bff8)
[   11.375492] bfa0:                                     b6bca568 
00000000 003fa0d6 aedf3d20
[   11.383811] bfc0: aedf4a28 b6bca6f8 b6bca73c b6bca710 b6bca748 
b6bca6f8 aedf4a28 b6bca6f8
[   11.392127] bfe0: b6bca590 b6bca548 aeddae15 aedeb660 200f0030 ffffffff
[   11.398954] ---[ end Kernel panic - not syncing: Attempted to kill 
init! exitcode=0x00000004 ]---

I am in the process of running a diff between configurations because 
nothing obvious jumps out as being problematic so far.
--
Florian




More information about the linux-arm-kernel mailing list