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

Message-Id: <20251210101108.969603-1-sunshaojie@kylinos.cn>
Date: Wed, 10 Dec 2025 18:11:08 +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 v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict.

Hi, Michal,

On Mon, 8 Dec 2025 15:31:52 +0100, Michal Koutný wrote:
>>>   root cgroup
>>>        |
>>>       A1  //MK: A4 A5 here?
>>>      /  \
>>>    A2    A3... //MK: A4 A5 or here?
>>>
>>> #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.
>
>If A4 is a sibling at the level of A1, then A2 must be stripped of its
>CPUs to honor the hierarchy hence the apparent unfairness.
>
>If A4 is a sibling at the level of A2 and they have different owning
>users, their respective cpuset.cpus should only be writable by A1's user
>(the one who distributes the cpus) so that any arbitration between the
>siblings is avoided.

Regardless of whether A1 through A5 belong to the same user or different
users, arbitration conflicts between sibling nodes can still occur (e.g.,
due to user misconfiguration). The key question is: when such a conflict
arises, should all sibling nodes be invalidated, or only the node that
triggered the conflict?

Thanks,
Sun Shaojie