linux-kernel - Re: [PATCH cgroup/for-6.18-fixes] cgroup: Skip showing PID 0 in cgroup.procs and cgroup.threads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aQ31cwAFCS4Tvb7T@slm.duckdns.org>
Date: Fri, 7 Nov 2025 03:34:43 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH cgroup/for-6.18-fixes] cgroup: Skip showing PID 0 in
 cgroup.procs and cgroup.threads

Hello,

On Fri, Nov 07, 2025 at 10:57:54AM +0100, Michal Koutný wrote:
> On Thu, Nov 06, 2025 at 12:07:45PM -1000, Tejun Heo <tj@...nel.org> wrote:
> > 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.

> > 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.
> 
> > 
> > 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.

-- 
tejun