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: <20251201094236.108081-1-sunshaojie@kylinos.cn>
Date: Mon,  1 Dec 2025 17:42:36 +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 Wed, 26 Nov 2025 15:13:13, Michal Koutný wrote:
>On Thu, Nov 20, 2025 at 09:05:57PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
>> >Do you actually want to achieve this or is it an implementation
>> >side-effect of the Case 1 scenario that you want to achieve?
>> 
>> Yes, this is indeed the functionality I intended to achieve, as I find it 
>> follows the same logic as Case 1.
>
>So you want to achieve a stable [1] set of CPUs for a cgroup that cannot
>be taken away from you by any sibling, correct?
>My reasoning is that the siblings should be under one management entity
>and therefore such overcommitment should be avoided already in the
>configuration. Invalidating all conflicting siblings is then the most
>fair result achievable.
>B1 is a second-class partition _only_ because it starts later or why is
>it OK to not fulfill its requirement?
>

If the siblings are under a single management entity, that certainly works.
But what if there are multiple administrative users? Should we really
violate other users' requirements just to satisfy one user's requirement?
Given this, first-come-first-served might be fairer.

>[1] Note that A1 should still watch its cpuset.cpus.partition if it
>takes exclusivity seriously because its cpus may be taken away by
>hot(un)plug or ancestry reconfiguration.

Thanks,
Sun Shaojie