On 6/22/24 08:13, Helge Deller wrote:
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?
No, I don't have hardware. I only have qemu. That is why I copied you and
the parisc mailing list. I would hope that someone can either confirm that
this is a real problem or that it is qemu related. If it is qemu related,
I'll just stop testing c3700 64-bit support with qemu on v6.1.y and other
branches if/when the problem shows up there 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...?!?
Sure, that is possible, though it is a bit unusual that it is only seen
in 6.1.95 and not in any other branches or releases.
In summary, please see this report as "This is a problem seen in qemu.
It may or may not be seen on real hardware". Maybe I should add this as a
common disclaimer to all my reports to avoid misunderstandings.
Thanks,
Guenter
