linux-kernel - Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict

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: <20251217090951.1444326-1-sunshaojie@kylinos.cn>
Date: Wed, 17 Dec 2025 17:09:51 +0800
From: Sun Shaojie <sunshaojie@...inos.cn>
To: chenridong@...weicloud.com
Cc: cgroups@...r.kernel.org,
	hannes@...xchg.org,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	llong@...hat.com,
	mkoutny@...e.com,
	shuah@...nel.org,
	sunshaojie@...inos.cn,
	tj@...nel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict

Hi, Ridong

On Sat, 13 Dec 2025 08:52:11 +0800, Chen Ridong wrote:
>On 2025/12/1 17:44, Sun Shaojie wrote:
>> Hi, Ridong,
>> 
>> On Thu, 27 Nov 2025 09:55:21, Chen Ridong wrote:
>>> I have to admit that I prefer the current implementation.
>>>
>>> At the very least, it ensures that all partitions are treated fairly[1]. Relaxing this rule would
>>> make it more difficult for users to understand why the cpuset.cpus they configured do not match the
>>> effective CPUs in use, and why different operation orders yield different results.
>> 
>> As for "different operation orders yield different results", Below is an
>> example that is not a corner case.
>> 
>>     root cgroup
>>       /    \
>>      A1    B1
>> 
>>  #1> echo "0" > A1/cpuset.cpus
>>  #2> echo "0-1" > B1/cpuset.cpus.exclusive --> return error
>> 
>>  #1> echo "0-1" > B1/cpuset.cpus.exclusive
>>  #2> echo "0" > A1/cpuset.cpus
>> 
>
>You're looking at one rule, but there's another one—Longman pointed out that setting cpuset.cpu
>should never fail.

Precisely because I know that setting cpuset.cpus should never fail,
I provided this example, which is why it demonstrates that "different
operation orders yield different results."

>>>
>>> In another scenario, if we do not invalidate the siblings, new leaf cpusets (marked as member)
>>> created under A1 will end up with empty effective CPUs—and this is not a desired behavior.
>>>
>>>   root cgroup
>>>        |
>>>       A1
>>>      /  \
>>>    A2    A3...
>>>
>>> #1> echo "0-1" > A1/cpuset.cpus
>>> #2> echo "root" > A1/cpuset.cpus.partition
>>> #3> echo "0-1" > A2/cpuset.cpus
>>> #4> echo "root" > A2/cpuset.cpus.partition
>>> mkdir A4
>>> mkdir A5
>>> echo "0" > A4/cpuset.cpus
>>> echo $$ > A4/cgroup.procs
>>> echo "1" > A5/cpuset.cpus
>>> echo $$ > A5/cgroup.procs
>>>
>> 
>> If A2...A5 all belong to the same user, and that user wants both A4 and A5 
>> to have effective CPUs, then the user should also understand that A2 needs
>> to be adjusted to "member" instead of "root".
>> 
>> if A2...A5 belong to different users, must satisfying user A4’s requirement
>> come at the expense of user A2’s requirement? That is not fair.
>> 
>
>Regarding cpuset usage with Docker: when binding CPUs at container startup, do you check the sibling
>CPUs in use? Without this check, A2 will not be invalidated.
>
>Your patch has been discussed for a while. It seems to make the rules more complex.

My aim is to safeguard the independence of sibling nodes while adhering to
existing rules. I continuously update the patch to uphold these rules, as
seen in the recently updated patch v6
(https://lore.kernel.org/cgroups/20251201093806.107157-1-sunshaojie@kylinos.cn/).

Thanks,
Sun Shaojie