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

[Guenter Roeck]

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@xxxxxxxxxxxxxxxxxxx) (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