linux-kernel - Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4gzorntzaig4vnskzkumnpvpqfbqrzaahlkn5c33cgtjdm5eef@gtvm3p2rihm7>
Date: Fri, 14 Nov 2025 17:14:45 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Chen Ridong <chenridong@...weicloud.com>
Cc: Sun Shaojie <sunshaojie@...inos.cn>, llong@...hat.com, 
	cgroups@...r.kernel.org, hannes@...xchg.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, shuah@...nel.org, tj@...nel.org
Subject: Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2

On Fri, Nov 14, 2025 at 09:29:20AM +0800, Chen Ridong <chenridong@...weicloud.com> wrote:
> After further consideration, I still suggest retaining this rule.

Apologies, I'm slightly lost which rule. I hope the new iteration from
Shaojie with both before/after tables will explain it.

> For am example:
>   Step                                       | A1's prstate | B1's prstate |
>   #1> mkdir -p A1                            | member       |              |
>   #2> echo "0-1" > A1/cpuset.cpus.exclusive  | member       |              |
>   #3> echo "root" > A1/cpuset.cpus.partition | root         |              |
>   #4> mkdir -p B1                            | root         | member       |
>   #5> echo "0" > B1/cpuset.cpus              | root invalid | member       |
> 
> Currently, we mark A1 as invalid. But similar to the logic in this patch, why must A1 be
> invalidated?

A1 is invalidated becase it doesn't have exclusive ownership of CPU 0
anymore.

> B1 could also use the parent's effective CPUs, right?

Here you assume some ordering between siblings treating A1 more
important than B1. But it's symmetrical in principle, no?

> This raises the question: Should we relax the restriction to allow a cpuset's cpus to be a subset of
> its siblings' exclusive_cpus, thereby keeping A1 valid? If we do this, users may struggle to
> understand what their cpuset.cpus.effective value is (and why it has that value)—contrary to their
> expectations.

Not only users, not only users. I think struggle is reduced when
the resulting state (valid/invalid, effective) doesn't depend on the
order in which individual cgroups are configured.

0.02€,
Michal

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