Re: [PATCH v2] pid_namespace: make zap_pid_ns_processes() freezable

[Bradley Morgan]

On 2 October 2026 21:28:20 BST, Aviv Vaknin <vaknins33@xxxxxxxxx> wrote:
>When the init of a pid namespace exits, zap_pid_ns_processes() waits
>until all other pids in the namespace are freed. A tracer outside the
>namespace that does not reap its traced zombies keeps those pids
>allocated, so this wait has no upper bound, and while it lasts every
>suspend attempt fails:
>
>  Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0):
>
>Neither wait is freezable. The first loop sleeps in do_wait(), which
>returns -ERESTARTSYS on the freezer's fake signal; the loop then clears
>TIF_SIGPENDING and waits again without ever freezing. The final loop
>sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING
>there, schedule() returns immediately after the first freeze attempt
>and the task spins until the wait ends.
>
>Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the
>freezer can freeze tasks waiting there directly, and in TASK_IDLE |
>TASK_FREEZABLE in the final loop, like coredump_task_exit() does.
>
>This was hit with Chromium-based browsers: crashpad ptrace-attaches the
>threads of a crashed renderer, which is a pid namespace init, and does
>not reap those killed during the dump.

Suggestion: We could do a ASCII table of the bug to make it "look" cool, I mean, you certainly don't have to.

My tag stands:

Reviewed-by: Bradley Morgan <brads@xxxxxxxxxxxxxx>

>
>Fixes: 3eb07c8c8adb ("pid namespaces: destroy pid namespace on init's death")
>Fixes: b9a985db9896 ("pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes")
>Cc: stable@xxxxxxxxxxxxxxx # 6.1+
>Suggested-by: Oleg Nesterov <oleg@xxxxxxxxxx>
>Assisted-by: Claude:claude-opus-5-5
>Signed-off-by: Aviv Vaknin <vaknins33@xxxxxxxxx>
>---
>v2:
>- Make do_wait() freezable instead of calling try_to_freeze() after
>  kernel_wait4() (Oleg).
>- Drop the comments.
>- Drop the acks and the review tag, since the approach changed.
>- Retested on v7.3-rc5 with the reproducer from v1, also unprivileged:
>  freezing completes in 0.001 s, the zap task stays idle, and reaping
>  the zombies still ends the wait.
>
>v1: https://lore.kernel.org/r/20261001121254.883973-1-vaknins33@xxxxxxxxx
>
> kernel/exit.c          | 2 +-
> kernel/pid_namespace.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/kernel/exit.c b/kernel/exit.c
>index 97686af89..b54cc7b2b 100644
>--- a/kernel/exit.c
>+++ b/kernel/exit.c
>@@ -1751,7 +1751,7 @@ static long do_wait(struct wait_opts *wo)
> 	add_wait_queue(&current->signal->wait_chldexit, &wo->child_wait);
> 
> 	do {
>-		set_current_state(TASK_INTERRUPTIBLE);
>+		set_current_state(TASK_INTERRUPTIBLE | TASK_FREEZABLE);
> 		retval = __do_wait(wo);
> 		if (retval != -ERESTARTSYS)
> 			break;
>diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
>index 8bc9edb40..127a5fd23 100644
>--- a/kernel/pid_namespace.c
>+++ b/kernel/pid_namespace.c
>@@ -269,7 +269,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
> 	 * free_pid() will awaken this task.
> 	 */
> 	for (;;) {
>-		set_current_state(TASK_INTERRUPTIBLE);
>+		set_current_state(TASK_IDLE | TASK_FREEZABLE);
> 		if (pid_ns->pid_allocated == init_pids)
> 			break;
> 		schedule();
>
>base-commit: ed14a591175bb5f56c2936b082cffb9e4b935e6d
>


--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/