linux-kernel - Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2

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: <lhfcykirz5afdzdc6wnroubsdhasww4gsfri4dxpzagiejjbep@322rtmyvwiyd>
Date: Thu, 13 Nov 2025 18:07:33 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Sun Shaojie <sunshaojie@...inos.cn>
Cc: llong@...hat.com, cgroups@...r.kernel.org, chenridong@...weicloud.com, 
	hannes@...xchg.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	shuah@...nel.org, tj@...nel.org
Subject: Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2

Hello.

On Thu, Nov 13, 2025 at 09:14:34PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
> In cgroup v2, a mutual overlap check is required when at least one of two
> cpusets is exclusive. However, this check should be relaxed and limited to
> cases where both cpusets are exclusive.
> 
> The table 1 shows the partition states of A1 and B1 after each step before
> applying this patch.
> 
> Table 1: Before applying the patch
>  Step                                       | A1's prstate | B1's prstate |
>  #1> mkdir -p A1                            | member       |              |
>  #2> echo "0-1" > A1/cpuset.cpus            | member       |              |
>  #3> echo "root" > A1/cpuset.cpus.partition | root         |              |
>  #4> mkdir -p B1                            | root         | member       |
>  #5> echo "0-3" > B1/cpuset.cpus            | root invalid | member       |
>  #6> echo "root" > B1/cpuset.cpus.partition | root invalid | root invalid |
> 
> After step #5, A1 changes from "root" to "root invalid" because its CPUs
> (0-1) overlap with those requested by B1 (0-3). However, B1 can actually
> use CPUs 2-3, so it would be more reasonable for A1 to remain as "root."

I remember there was the addition of cgroup_file_notify() for the
cpuset.cpus.partition so that such changes can be watched for.

I may not be seeing whole picture, so I ask -- why would it be "more
reasonable" for A1 to remain root. From this description it looks like
you'd silently convert B1's effective cpus to 2-3 but IIUC the code
change that won't happen but you'd reject the write of "0-3" instead.

Isn't here missing Table 2: After applying the patch? I'm asking because
of the number 1 but also because it'd make the intention clearer
;-), perhaps with a column for cpuset.cpus.effective.

Thanks,
Michal

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