On 6/22/24 16:58, Guenter Roeck wrote:
[ Copying parisc maintainers - maybe they can test on real hardware ]
On 6/19/24 05:54, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.95 release.
There are 217 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 Fri, 21 Jun 2024 12:55:11 +0000.
Anything received after that time might be too late.
...
Oleg Nesterov <oleg@xxxxxxxxxx>
zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING
I can not explain it, but this patch causes all my parisc64 (C3700)
boot tests to crash. There are lots of memory corruption BUGs such as
[ 0.000000] =============================================================================
[ 0.000000] BUG kmalloc-96 (Not tainted): Padding overwritten. 0x0000000043411dd0-0x0000000043411f5f @offset=3536
ultimately followed by
[ 0.462562] Unaligned handler failed, ret = -14
...
[ 0.469160] IAOQ[0]: idr_alloc_cyclic+0x48/0x118
[ 0.469372] IAOQ[1]: idr_alloc_cyclic+0x54/0x118
[ 0.469548] RP(r2): __kernfs_new_node.constprop.0+0x160/0x420
[ 0.469782] Backtrace:
[ 0.469928] [<00000000404af108>] __kernfs_new_node.constprop.0+0x160/0x420
[ 0.470285] [<00000000404b0cac>] kernfs_new_node+0xbc/0x118
[ 0.470523] [<00000000404b158c>] kernfs_create_empty_dir+0x54/0xf0
[ 0.470756] [<00000000404b665c>] sysfs_create_mount_point+0x4c/0xb0
[ 0.470996] [<00000000401181cc>] cgroup_init+0x5b4/0x738
[ 0.471213] [<0000000040102220>] start_kernel+0x1238/0x1308
[ 0.471429] [<0000000040107c90>] start_parisc+0x188/0x1d0
...
[ 0.474956] Kernel panic - not syncing: Attempted to kill the idle task!
SeaBIOS wants SYSTEM RESET.
This is with qemu v9.0.1.
Just to be sure, did you tested the same kernel on physical hardware as well?
Please note, that 64-bit hppa (C3700) support in qemu was just recently added
and is still considered experimental.
So, maybe it's not a bug in the source, but in qemu...?!?
Reverting this patch fixes the problem (I tried several times to be sure
since I don't see the connection). I don't see the problem in any other
branch. Bisect log is attached for reference.
Guenter
---
# bad: [a6398e37309000e35cedb5cc328a0f8d00d7d7b9] Linux 6.1.95
# good: [eb44d83053d66372327e69145e8d2fa7400a4991] Linux 6.1.94
git bisect start 'HEAD' 'v6.1.94'
# good: [f17443d52d805c9a7fab5e67a4e8b973626fe1cd] cachefiles: resend an open request if the read request's object is closed
git bisect good f17443d52d805c9a7fab5e67a4e8b973626fe1cd
# good: [cc09e1d3519feab823685f4297853d468f44549d] iio: imu: inv_icm42600: delete unneeded update watermark call
git bisect good cc09e1d3519feab823685f4297853d468f44549d
# good: [b7b6bc60edb2132a569899bcd9ca099a0556c6ee] intel_th: pci: Add Granite Rapids SOC support
git bisect good b7b6bc60edb2132a569899bcd9ca099a0556c6ee
# good: [35e395373ecd14b64da7d54f565927a9368dcf20] mptcp: pm: update add_addr counters after connect
git bisect good 35e395373ecd14b64da7d54f565927a9368dcf20
# good: [29d35f0b53d4bd82ebc37c500a8dd73da61318ff] serial: 8250_dw: fall back to poll if there's no interrupt
git bisect good 29d35f0b53d4bd82ebc37c500a8dd73da61318ff
# good: [ea25a4c0de5700928c7fd0aa789eee39a457ba95] misc: microchip: pci1xxxx: Fix a memory leak in the error handling of gp_aux_bus_probe()
git bisect good ea25a4c0de5700928c7fd0aa789eee39a457ba95
# good: [e44999ec0b49dca9a9a2090c5432d893ea4f8d20] i2c: designware: Fix the functionality flags of the slave-only interface
git bisect good e44999ec0b49dca9a9a2090c5432d893ea4f8d20
# bad: [edd2754a62bee8d97b4808a15de024f66a1ddccf] zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING
git bisect bad edd2754a62bee8d97b4808a15de024f66a1ddccf
# first bad commit: [edd2754a62bee8d97b4808a15de024f66a1ddccf] zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING
