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: <b6d9088e-bd35-47c5-a891-4ad3705fd1a6@huaweicloud.com>
Date: Sat, 15 Nov 2025 17:51:23 +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 10:01, Chen Ridong wrote:
> 
> 
> 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.
> 

This may trigger another related corner case, I sent a patch to fix it:

https://lore.kernel.org/cgroups/20251115093140.1121329-1-chenridong@huaweicloud.com/T/#mfc4157e23d253b71ef9a2cfa5cb54bf41449840c

-- 
Best regards,
Ridong


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ