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: <b3umm7mcucmztqqnp6x4e6ichqcml2r2bg7d2xairxajyqrzbt@3nshatmt2evo>
Date: Mon, 8 Dec 2025 15:31:52 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Sun Shaojie <sunshaojie@...inos.cn>
Cc: chenridong@...weicloud.com, cgroups@...r.kernel.org, 
	hannes@...xchg.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	llong@...hat.com, shuah@...nel.org, tj@...nel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on
 cpuset.cpus conflict.

Hello.

On Mon, Dec 01, 2025 at 05:44:47PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
> 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

Here it is a combination of remote cs local partitions.
I'd like to treat the two approaches separately and better not consider
their combination.

The idea (and permissions check AFACS) behind remote partitions is to
allow "stealing" CPU ownership so cpuset.cpus.exclusive has different
behavior.

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

0.02€,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)