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: <765120d5-1887-4376-b779-8294df137b9d@huaweicloud.com>
Date: Sat, 15 Nov 2025 10:01:21 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>,
 Sun Shaojie <sunshaojie@...inos.cn>
Cc: llong@...hat.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



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.)

Before applying the patch, the behavior I got:

	# cd /sys/fs/cgroup/
	# mkdir A1
	# mkdir B1
	# echo root > A1/cpuset.cpus.partition
	# echo 0-1 > A1/cpuset.cpus
	# cat A1/cpuset.cpus.partition
	root
	# echo root > B1/cpuset.cpus.partition
	# echo 1-2 > B1/cpuset.cpus  # A1 is exclusive, invalidate both A1 and B1
	# cat A1/cpuset.cpus.partition
	root invalid
	# cat B1/cpuset.cpus.partition
	root invalid (cpuset.cpus and cpuset.cpus.exclusive are empty)
	# echo root > B1/cpuset.cpus.partition
	# cat B1/cpuset.cpus.partition
	root invalid (Cpu list in cpuset.cpus not exclusive)
	# echo root > A1/cpuset.cpus.partition
	# cat A1/cpuset.cpus.partition
	root invalid (Cpu list in cpuset.cpus not exclusive)
	#

After applying the patch, the behavior I got:

	# cd /sys/fs/cgroup/
	# mkdir A1
	#  mkdir B1
	# echo root > A1/cpuset.cpus.partition
	# echo 0-1 > A1/cpuset.cpus
	# cat A1/cpuset.cpus.partition
	root
	# echo root > B1/cpuset.cpus.partition
	# echo 1-2 > B1/cpuset.cpus # A1 is exclusive, B1 is going to be exclusive
	# cat A1/cpuset.cpus.partition
	root
	# cat B1/cpuset.cpus.partition # A1 and B1 should be invalid.
	root
	# echo member > B1/cpuset.cpus.partition
	# echo root > B1/cpuset.cpus.partition
	# cat A1/cpuset.cpus.partition
	root
	# cat B1/cpuset.cpus.partition
	root invalid (Cpu list in cpuset.cpus not exclusive)
	# echo member > A1/cpuset.cpus.partition
	# echo root > B1/cpuset.cpus.partition
	# echo root > A1/cpuset.cpus.partition
	# cat A1/cpuset.cpus.partition
	root invalid (Cpu list in cpuset.cpus not exclusive)
	# cat B1/cpuset.cpus.partition
	root

After applying the patch, The result is unexpected.

-- 
Best regards,
Ridong