Re: [PATCH 5.15 00/91] 5.15.108-rc1 review

Guenter Roeck
2023-04-19T03:55:15Z

On Tue, Apr 18, 2023 at 02:21:04PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.108 release.
> There are 91 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 20 Apr 2023 12:02:44 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 160 pass: 146 fail: 14
Failed builds:
alpha:allmodconfig
arm:omap2plus_defconfig
arm:vexpress_defconfig
arm64:defconfig
i386:defconfig
ia64:defconfig
mips:defconfig
parisc:allmodconfig
parisc64:generic-64bit_defconfig
powerpc:defconfig
powerpc:ppc64e_defconfig
powerpc:cell_defconfig
s390:defconfig
x86_64:defconfig
Qemu test results:
total: 499 pass: 452 fail: 47
Failed tests:
mipsel64:64r6el_defconfig:notests:nonet:smp:ide:hd
mipsel64:64r6el_defconfig:notests:nonet:smp:ide:hd
mipsel64:64r6el_defconfig:notests:nonet:smp:ide:cd
<all riscv32, riscv64, s390>

Build failures:

kernel/cgroup/cpuset.c: In function 'cpuset_can_fork':
kernel/cgroup/cpuset.c:2979:30: error: 'cgroup_mutex' undeclared

riscv32/riscv64 images crash.

[ 0.000000] Linux version 5.15.108-rc1-00092-g0b6a5617247c (groeck@server.roeck-us.net) (riscv32-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.39) #1 SMP Tue Apr 18 14:19:32 PDT 2023
[ 0.000000] random: crng init done
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] Machine model: riscv-virtio,qemu
[ 0.000000] earlycon: uart8250 at MMIO 0x10000000 (options '115200')
[ 0.000000] printk: bootconsole [uart8250] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] Unable to handle kernel paging request at virtual address 00600001
[ 0.000000] Oops [#1]
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.108-rc1-00092-g0b6a5617247c #1
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] epc : fdt_check_header+0x6/0x1ac
[ 0.000000] ra : __unflatten_device_tree+0x32/0x106
[ 0.000000] epc : c04cf1dc ra : c0859f08 sp : c1c01f30
[ 0.000000] gp : c1d6dca8 tp : c1c0a9c0 t0 : 00000000
[ 0.000000] t1 : c100f4fc t2 : 00000000 s0 : c1c01f40
[ 0.000000] s1 : c0c25000 a0 : 00600000 a1 : 00000000
[ 0.000000] a2 : c1d74044 a3 : c0c253ae a4 : 00000000
[ 0.000000] a5 : c173a000 a6 : c1c01f2c a7 : 00000001
[ 0.000000] s2 : 00600000 s3 : c1d74044 s4 : c0c253ae
[ 0.000000] s5 : 00000000 s6 : 00000000 s7 : 8001b020
[ 0.000000] s8 : 00002000 s9 : 800312e4 s10: 00000000
[ 0.000000] s11: 00000000 t3 : 00000000 t4 : 00000000
[ 0.000000] t5 : a0000000 t6 : 80400000
[ 0.000000] status: 00000100 badaddr: 00600001 cause: 0000000d
[ 0.000000] [<c04cf1dc>] fdt_check_header+0x6/0x1ac
[ 0.000000] ---[ end trace 6977e3ccdb629cdf ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

Bisect points to

08ace525df14 riscv: Do not set initial_boot_params to the linear address of the dtb

This is not surprising, because that commit says:

"early_init_dt_verify() is already called in parse_dtb() and since the dtb
address does not change anymore (it is now in the fixmap region), no need
to reset initial_boot_params by calling early_init_dt_verify() again.
"

However, the patch which actually moves the early dtb mapping into the
fixmap region was not backported (and looks quite invasive to me).
That makes me wonder ... why is this a stable release candidate in the
first place ?

Guenter