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

Message-Id: <20251115112453.875799-1-sunshaojie@kylinos.cn>
Date: Sat, 15 Nov 2025 19:24:53 +0800
From: Sun Shaojie <sunshaojie@...inos.cn>
To: mkoutny@...e.com
Cc: cgroups@...r.kernel.org,
	chenridong@...weicloud.com,
	hannes@...xchg.org,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	llong@...hat.com,
	shuah@...nel.org,
	sunshaojie@...inos.cn,
	tj@...nel.org
Subject: Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2

On 2025/11/15 0:15, Michal Koutný wrote:
>On Fri, Nov 14, 2025 at 02:24:48PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
>> 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.
>
>So the new list of reasons why configured cpuset's cpus change are:
>- hotplug,
>- ancestor's config change,
>- stealing by a sibling (new).
>
>IIUC, the patch proposes this behavior:
>
>  echo root >A1.cpuset.partition
>  echo 0-1 >A1.cpuset.cpus
>  
>  echo root >B1.cpuset.partition
>  echo 1-2 >B1.cpuset.cpus	# invalidates A1
>  
>  echo 0-1 >A1.cpuset.cpus	# invalidates B1
>  
>  ping-pong over CPU 1 ad libitum
>
>I think the right (tm) behavior would be not to depend on the order in
>which config is applied to siblings, i.e.
>
>  echo root >A1.cpuset.partition
>  echo 0-1 >A1.cpuset.cpus
>  
>  echo root >B1.cpuset.partition
>  echo 1-2 >B1.cpuset.cpus	# invalidates both A1 and B1
>
>  echo 0-1 >A1.cpuset.cpus	# no change anymore
>
>(I hope my example sheds some light on my understanding of the situation
>and desired behavior.)

Hi, Michal

The current patch is flawed and will be fixed in patch v3. However, the 
example you provided also has issues. Below, I’ll explain your example.

Table 1: current result for your example 1.
 Step                                | A1's prstate | B1's prstate |
 #1> echo root > A1.cpuset.partition | root invalid |              |
 #2> echo 0-1 > A1.cpuset.cpus       | root         |              |
 #3> echo root > B1.cpuset.partition | root         | root invalid |
 #4> echo 1-2 > B1.cpuset.cpus       | root invalid | root invalid |
 #5> echo 0-1 >A1.cpuset.cpus        | root invalid | root invalid |

After step #4, both A1 and B1 are already in the "root invalid" state.
Therefore, B1 becoming "root invalid" is not caused by step #5, but was 
already in the "root invalid" state from the beginning.

Table 2: this is my expected result 
 Step                                | A1's prstate | B1's prstate |
 #1> echo root > A1.cpuset.partition | root invalid |              |
 #2> echo 0-1 > A1.cpuset.cpus       | root         |              |
 #3> echo root > B1.cpuset.partition | root         | root invalid |
 #4> echo 1-2 > B1.cpuset.cpus       | root         | root invalid |
 #5> echo 0-1 >A1.cpuset.cpus        | root         | root invalid |

If A1 is "root", and B1 is not "root", Our goal is to ensure that B1's 
behavior does not affect the "root" state of A1. Similarly, when B1's 
"cpuset.cpus.effective" is non-empty, we strive to ensure A1's own behavior
does not affect its "root" state as much as possible.

In summary, the purpose of submitting this patch is to ensure that, when 
only one of A1 and B1 is "root", the actions of one party do not affect the
"root" state of the other.

Thanks,
Sun Shaojie