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: <20251114062448.685754-1-sunshaojie@kylinos.cn>
Date: Fri, 14 Nov 2025 14:24:48 +0800
From: Sun Shaojie <sunshaojie@...inos.cn>
To: mkoutny@...e.com
Cc: llong@...hat.com,
	chenridong@...weicloud.com,
	cgroups@...r.kernel.org,
	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

Hi, Michal

On 2025/11/14 01:07, Michal Koutný wrote:
>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.
>

The desired outcome is that after step #5, although B1 writes "0-3" to 
cpuset.cpus, A1 can still remain as "root", and B1 ends up with effective 
CPUs of 2-3. In summary, We want to avoid A1's invalidation when B1 
changes its cpuset.cpus. Because cgroup v2 allows the effective CPU mask 
of a cpuset to differ from its requested mask.

Indeed, this issue was discussed in detail during the v1 review.
https://lore.kernel.org/cgroups/c8e234f4-2c27-4753-8f39-8ae83197efd3@redhat.com/T/#u

>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 for the suggestion. I will update the patch description accordingly.

Thanks,
Sun Shaojie