linux-kernel - Re: [PATCH 1/2] cgroup: Print v1 cgroup.procs and tasks without pidlists

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: <ZO5cx9UhqBzP2QX-@slm.duckdns.org>
Date:   Tue, 29 Aug 2023 11:01:59 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
        Zefan Li <lizefan.x@...edance.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Firo Yang <firo.yang@...e.com>
Subject: Re: [PATCH 1/2] cgroup: Print v1 cgroup.procs and tasks without
 pidlists

Hello, Michal.

On Wed, Aug 23, 2023 at 07:48:03PM +0200, Michal Koutný wrote:
> pidlists are structure that allows printing cgroup member tasks in
> sorted order and with proper pidns (in)visibility.
> 
> The promise of sorted output was removed in the commit 7823da36ce8e
> ("cgroups: update documentation of cgroups tasks and procs files") (more
> than 13 years ago at the time of writing this).

While this is true, I'm not sure it'd be a good idea to change the behavior
after all these years. Whoever is still using cgroup1 likely doens't mean to
update their code at all and it's difficult to rule out odd-ball users that
might have been depending on the ordered output knowingly or unknowingly.

> On systems that still use v1 hierarchies (e.g. systemd in non-unified
> mode), pidlists are problematic because:
> a) their cache unnecessarily busies workqueues (cgroup_pidlist_destroy_wq)
> b) PID recycling [1] may lead to logging noise:
> > seq_file: buggy .next function kernfs_seq_next did not update position index

While I like the code reduction, I wonder whether the right course of action
is just fixing the warning here.

Thanks.

-- 
tejun