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: <4ab8a086-4200-45c0-9583-abf6e52a354a@huaweicloud.com>
Date: Sat, 13 Dec 2025 08:52:11 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Sun Shaojie <sunshaojie@...inos.cn>
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, tj@...nel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on
 cpuset.cpus conflict.



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.

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

>>
>> [1]: "B1 is a second-class partition only because it starts later or why is it OK to not fulfill its
>> requirement?" --Michal.
> 
> Thanks,
> Sun Shaojie

-- 
Best regards,
Ridong