linux-kernel - Re: [PATCH] cgroup/cpuset: Move procfs cpuset attribute under cgroup-v1.c

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <l7o4dygoe2h7koumizjqljs7meqs4dzngkw6ugypgk6smqdqbm@ocl4ldt5izmr>
Date: Thu, 16 Jan 2025 15:05:32 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Waiman Long <llong@...hat.com>
Cc: linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>, 
	Chen Ridong <chenridong@...wei.com>
Subject: Re: [PATCH] cgroup/cpuset: Move procfs cpuset attribute under
 cgroup-v1.c

On Thu, Jan 16, 2025 at 08:40:56AM -0500, Waiman Long <llong@...hat.com> wrote:
> I do have some reservation in taking out /proc/<pid>/cpuset by default as
> CPUSETS_V1 is off by default. This may break some existing user scripts.

Cannot be /proc/$pid/cpuset declared a v1 feature?
Similar to cpuset fs (that is under CPUSETS_V1). If there's a breakage,
the user is not non-v1 ready and CPUSETS_V1 must be enabled.

> Also the statement that the cpuset file is the same as the path in cgroup
> file in unified hierarchy is not true if that cgroup doesn't have cpuset
> enabled.

(I tried to capture that with the "effective path", I should reword it
more clearly.)

Thanks,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)