Skip to contentSkip to conversation

cgroup: Skip showing PID 0 in cgroup.procs and cgroup.threads

PATCH Applied Tejun Heo 3 participants 6 messages Nov 6, 2025 – Nov 11, 2025

Subsystems (2)
Stable branch cgroup
lore
Share & tools
lore

Tejun Heo

author maintainer
#0 lore raw

PATCH 1/1 cgroup: Skip showing PID 0 in cgroup.procs and cgroup.threads

css_task_iter_next() pins and returns a task, but the task can do whatever between that and cgroup_procs_show() being called, including dying and losing its PID. When that happens, task_pid_vnr() returns 0.

d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") makes this more likely as tasks now stay iterable with css_task_iter_next() until the last schedule is complete, which can be after the task has lost its PID.

Showing "0" in cgroup.procs or cgroup.threads is confusing and can lead to surprising outcomes. For example, if a user tries to kill PID 0, it kills all processes in the current process group.

Skip entries with PID 0 by returning SEQ_SKIP.

Cc [email protected]
Signed-off-by Tejun Heo <[email protected]>
---
 kernel/cgroup/cgroup.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
kernel/cgroup/cgroup.c +11 -0
@@ -5287,6 +5287,17 @@ static void *cgroup_procs_start(struct s
 
 static int cgroup_procs_show(struct seq_file *s, void *v)
 {
+	pid_t pid = task_pid_vnr(v);
+
+	/*
+	 * css_task_iter_next() could have visited a task which has already lost
+	 * its PID but is not dead yet or the task could have been unhashed
+	 * since css_task_iter_next(). In such cases, $pid would be 0 here.
+	 * Don't confuse userspace with it.
+	 */
+	if (unlikely(!pid))
+		return SEQ_SKIP;
+
 	seq_printf(s, "%d\n", task_pid_vnr(v));
 	return 0;
 }
build bot
#1 lore raw
FYI: kernel test robot notices the stable kernel rule is not satisfied.

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3

Rule: The upstream commit ID must be specified with a separate line above the commit text.
Subject: [PATCH cgroup/for-6.18-fixes] cgroup: Skip showing PID 0 in cgroup.procs and cgroup.threads

Link https://lore.kernel.org/stable/2016aece61b4da7ad86c6eca2dbcfd16%40kernel.org open here

Please ignore this mail if the patch is not relevant for upstream.

Signature · 2 lines
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
maintainer
#3 lore raw
In reply to Tejun Heo

Hello.

Quoted 3 lines · Tejun Heo

css_task_iter_next() pins and returns a task, but the task can do whatever between that and cgroup_procs_show() being called, including dying and losing its PID. When that happens, task_pid_vnr() returns 0.

task_pid_vnr() would return 0 also when the process is not from reader's pidns (IMO more common than the transitional effect).

Quoted 3 lines

Showing "0" in cgroup.procs or cgroup.threads is confusing and can lead to surprising outcomes. For example, if a user tries to kill PID 0, it kills all processes in the current process group.

It's still info about present processes.

Quoted 2 lines

Skip entries with PID 0 by returning SEQ_SKIP.

It's likely OK to skip for these exiting tasks but with the external pidns tasks in mind, reading cgroup.procs now may give false impression of an empty cgroup.

Where does the 0 from of the exiting come from? (Could it be distinguished from foreign pidns?)

Thanks,
Michal

author maintainer
#4 lore raw

Hello,

Quoted 7 lines · Michal Koutný
Quoted 3 lines · Tejun Heo

css_task_iter_next() pins and returns a task, but the task can do whatever between that and cgroup_procs_show() being called, including dying and losing its PID. When that happens, task_pid_vnr() returns 0.

task_pid_vnr() would return 0 also when the process is not from reader's pidns (IMO more common than the transitional effect).

Hmm... haven't thought about that.

Quoted 7 lines
Quoted 3 lines

Showing "0" in cgroup.procs or cgroup.threads is confusing and can lead to surprising outcomes. For example, if a user tries to kill PID 0, it kills all processes in the current process group.

It's still info about present processes.

Quoted 1 line
Quoted 8 lines
Quoted 1 line

Skip entries with PID 0 by returning SEQ_SKIP.

It's likely OK to skip for these exiting tasks but with the external pidns tasks in mind, reading cgroup.procs now may give false impression of an empty cgroup.

Where does the 0 from of the exiting come from? (Could it be distinguished from foreign pidns?)

Yeah, I think it can be distinguished. We just need to check whether the task has pid attached at all after getting 0 return from task_pid_vnr().

Thanks.

Signature · 1 line
tejun
author maintainer
#5 lore raw
Quoted 26 lines · Tejun Heo

Hello,

Quoted 7 lines · Michal Koutný
Quoted 3 lines · Tejun Heo

css_task_iter_next() pins and returns a task, but the task can do whatever between that and cgroup_procs_show() being called, including dying and losing its PID. When that happens, task_pid_vnr() returns 0.

task_pid_vnr() would return 0 also when the process is not from reader's pidns (IMO more common than the transitional effect).

Hmm... haven't thought about that.

Quoted 13 lines
Quoted 3 lines

Showing "0" in cgroup.procs or cgroup.threads is confusing and can lead to surprising outcomes. For example, if a user tries to kill PID 0, it kills all processes in the current process group.

It's still info about present processes.

Quoted 2 lines

Skip entries with PID 0 by returning SEQ_SKIP.

It's likely OK to skip for these exiting tasks but with the external pidns tasks in mind, reading cgroup.procs now may give false impression of an empty cgroup.

Quoted 5 lines
Quoted 2 lines

Where does the 0 from of the exiting come from? (Could it be distinguished from foreign pidns?)

Yeah, I think it can be distinguished. We just need to check whether the task has pid attached at all after getting 0 return from task_pid_vnr().

Let me drop this patch for now.

Thanks.

Signature · 1 line
tejun