From: Tao Cui <cui.tao@linux.dev>
To: mt4022@columbia.edu, "Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>
Cc: cui.tao@linux.dev,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
tz2294@columbia.edu, stable@vger.kernel.org
Subject: Re: [PATCH] cgroup/freezer: walk exiting tasks in the v1 freezer
Date: Wed, 4 Nov 2026 21:25:10 +0800 [thread overview]
Message-ID: <57f4dd69-a326-4802-b9b3-f715568b8ea4@linux.dev> (raw)
In-Reply-To: <20261103-cgroup-freezer-exiting-v1-1-00d43b443747@columbia.edu>
Hi Mani,
在 2026/11/4 02:09, Mani Tofigh via B4 Relay 写道:
> From: Mani Tofigh <mt4022@columbia.edu>
>
> An exiting task can stay frozen after its v1 freezer cgroup is thawed.
> Since commit a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup")
> the css task walk hides an exiting task once its process has no live
> threads left. That count drops when another thread of the process
> exits, which can happen between the freeze and the thaw walk. A pid
> namespace init hits this easily since it waits freezably in
> zap_pid_ns_processes() after commit 81933038f5e2 ("pid_namespace: make
> zap_pid_ns_processes() freezable"):
>
> Task A (pid ns init) Task B (A's thread) Task C
> do_exit()
> exit_signals()
> do_exit()
> zap_pid_ns_processes()
> write FROZEN
> /* A frozen */
> /* live count 0 */
> write THAWED
> /* A skipped */
>
> A then stays frozen even after SIGKILL:
>
> [ 10.775155] task:fz-init state:D stack:28152 pid:65 tgid:65 ppid:1 task_flags:0xc0004c flags:0x00080000
> [ 10.775176] Call Trace:
> [ 10.775180] <TASK>
> [ 10.775188] __schedule+0x10f1/0x4760
> [ 10.775252] schedule+0xd7/0x2c0
> [ 10.775265] zap_pid_ns_processes+0x2c7/0x5f0
> [ 10.775346] do_exit+0x1bf4/0x2560
> [ 10.775403] __x64_sys_exit+0x3d/0x50
> [ 10.775414] x64_sys_call+0x156c/0x1570
> [ 10.775425] do_syscall_64+0xfb/0x590
> [ 10.775450] entry_SYSCALL_64_after_hwframe+0x77/0x7f
> [ 10.775529] </TASK>
>
> Use CSS_TASK_ITER_WITH_DEAD in the three v1 freezer walks so they all
> see the same tasks, as commit 60f21a264930 ("cgroup, sched_ext: Include
> exiting tasks in cgroup iter") did for sched_ext. With the fix, A is
> thawed and exits.
>
Thanks for the clear writeup and reproducer. Ran freezev1.c against
next-20261103 on a 2-vCPU VM. Base reproduced the hang on round 1
(5.1s), with the patch 600s / 6124 rounds ran clean.
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Tested-by: Tao Cui <cuitao@kylinos.cn>
Thanks,
Tao
> This bug was identified and confirmed with the help of a deterministic
> hypervisor currently under development. The C reproducer below however
> hits it within about 10s.
>
> Fixes: a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mani Tofigh <mt4022@columbia.edu>
> ---
> Reproducer: https://github.com/manitofigh/files/blob/main/linux-repros/freezev1.c
> ---
> kernel/cgroup/legacy_freezer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/cgroup/legacy_freezer.c b/kernel/cgroup/legacy_freezer.c
> index 8545e0d1ba3d..bd11047f2311 100644
> --- a/kernel/cgroup/legacy_freezer.c
> +++ b/kernel/cgroup/legacy_freezer.c
> @@ -265,7 +265,7 @@ static void update_if_frozen(struct cgroup_subsys_state *css)
> rcu_read_unlock();
>
> /* are all tasks frozen? */
> - css_task_iter_start(css, 0, &it);
> + css_task_iter_start(css, CSS_TASK_ITER_WITH_DEAD, &it);
>
> while ((task = css_task_iter_next(&it))) {
> if (freezing(task) && !frozen(task))
> @@ -309,7 +309,7 @@ static void freeze_cgroup(struct freezer *freezer)
> struct css_task_iter it;
> struct task_struct *task;
>
> - css_task_iter_start(&freezer->css, 0, &it);
> + css_task_iter_start(&freezer->css, CSS_TASK_ITER_WITH_DEAD, &it);
> while ((task = css_task_iter_next(&it)))
> freeze_task(task);
> css_task_iter_end(&it);
> @@ -320,7 +320,7 @@ static void unfreeze_cgroup(struct freezer *freezer)
> struct css_task_iter it;
> struct task_struct *task;
>
> - css_task_iter_start(&freezer->css, 0, &it);
> + css_task_iter_start(&freezer->css, CSS_TASK_ITER_WITH_DEAD, &it);
> while ((task = css_task_iter_next(&it)))
> __thaw_task(task);
> css_task_iter_end(&it);
>
> ---
> base-commit: fffbdad76a57eed26cff1be19f4cbb407f0b6e7c
> change-id: 20261102-cgroup-freezer-exiting-c7f60e4c3200
>
> Best regards,
> --
> Mani Tofigh <mt4022@columbia.edu>
next prev parent reply other threads:[~2026-11-04 13:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 18:09 [PATCH] cgroup/freezer: walk exiting tasks in the v1 freezer Mani Tofigh via B4 Relay
2026-11-03 18:09 ` Mani Tofigh
2026-11-04 13:25 ` Tao Cui [this message]
2026-11-05 18:05 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57f4dd69-a326-4802-b9b3-f715568b8ea4@linux.dev \
--to=cui.tao@linux.dev \
--cc=bigeasy@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=mt4022@columbia.edu \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=tz2294@columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.