zap_pid_ns_processes() gets stuck in a busy loop when zombie processes are in namespace
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Committed
|
Medium
|
Matthew Ruffell | ||
Noble |
Fix Committed
|
Medium
|
Matthew Ruffell |
Bug Description
BugLink: https:/
[Impact]
A deadlock can occur in zap_pid_
zap_pid_
A oops is:
Watchdog: BUG: soft lockup - CPU#3 stuck for 276s! [rcudeadlock:1836]
CPU: 3 PID: 1836 Comm: rcudeadlock Tainted: G L 5.15.0-117-generic #127-Ubuntu
RIP: 0010:_raw_
Code: f0 0f b1 17 74 08 31 c0 5d c3 cc cc cc cc b8 01 00 00 00 5d c3 cc cc cc cc 0f 1f 00 0f 1f 44 00 00 b8 00 02 00 00 f0 0f c1 07 <a9> ff 01 00 00 75 05 c3 cc cc cc cc 55 48 89 e5 e8 4d 79 36 ff 5d
CR2: 000000c0002b0000
Call Trace:
<IRQ>
? show_trace_
? show_trace_
? kernel_
? show_regs.
? show_regs.
? watchdog_
? lockup_
? __hrtimer_
? read_hv_
? hrtimer_
? hv_stimer0_
? __sysvec_
? sysvec_
</IRQ>
<TASK>
? asm_sysvec_
? _raw_read_
? do_wait+0xa0/0x310
kernel_
? thread_
zap_pid_
forget_
exit_notify+
do_exit+
do_group_
get_signal+
arch_do_
? __x64_sys_
exit_to_
exit_to_
syscall_
? x64_sys_
do_syscall_
? __io_uring_
? fput+0x13/0x20
? __do_sys_
? __smp_call_
? exit_to_
? syscall_
? x64_sys_
? do_syscall_
? try_to_
? wake_up_q+0x50/0x90
? futex_wake+
? do_futex+
? __x64_sys_
? switch_
? exit_to_
? syscall_
? x64_sys_
? do_syscall_
? do_user_
? exit_to_
? irqentry_
? irqentry_
? exc_page_
entry_
</TASK>
There is no known workaround.
[Fix]
This was fixed in the below commit in 6.10-rc5:
commit 7fea700e04bd3f4
Author: Oleg Nesterov <email address hidden>
Date: Sat Jun 8 14:06:16 2024 +0200
Subject: zap_pid_
Link: https:/
This patch has made its way to upstream stable, and is already applied to Ubuntu
kernels.
[Testcase]
There are two possible testcases to reproduce this issue.
This reproducer is courtesy of Rachel Menge, using the reproducers in her github repo:
https:/
Start a Jammy or Noble VM on Azure, D8sV3 will be plenty.
$ git clone https:/
npm repro:
Install Docker.
$ sudo docker run telescope.
$ ./rcu-npm-repro.sh
go repro:
$ go mod init rcudeadlock.go
$ go mod tidy
$ CGO_ENABLED=0 go build -o ./rcudeadlock ./
$ sudo ./rcudeadlock
Look at dmesg. After some minutes, you should see the hung task timeout from the impact section.
[Where problems can occur]
We are clearing TIF_NOTIFY_SIGNAL in the child, in order for signal_pending() to return false and not lead us to a busy wait loop.
This change should work as intended.
If a regression were to occur, it could potentially affect all processes in namespaces.
[Other Info]
Upstream mailing list discussion:
https:/
Changed in linux (Ubuntu): | |
status: | New → Fix Released |
Changed in linux (Ubuntu Jammy): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Noble): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Jammy): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Noble): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Jammy): | |
assignee: | nobody → Matthew Ruffell (mruffell) |
Changed in linux (Ubuntu Noble): | |
assignee: | nobody → Matthew Ruffell (mruffell) |
description: | updated |
tags: | added: sts |
This should land in 5.15.0-121-generic and 6.8.0-44-generic.