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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4ff564c4-a2c3-4599-8e7f-762380f44153@huaweicloud.com>
Date: Sat, 15 Nov 2025 08:58:05 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.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 2025/11/15 0:14, Michal Koutný wrote:
> 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.
> 

The rule has changed in this patch from "If either cpuset is exclusive, check if they are mutually
exclusive" to
"If both cpusets are exclusive, check if they are mutually exclusive"

  -	/* If either cpuset is exclusive, check if they are mutually exclusive */
  -	if (is_cpu_exclusive(cs1) || is_cpu_exclusive(cs2))
  +	/* If both cpusets are exclusive, check if they are mutually exclusive */
  +	if (is_cpu_exclusive(cs1) && is_cpu_exclusive(cs2))
  +		return !cpusets_are_exclusive(cs1, cs2);

I suggest not modifying this rule and keeping the original logic intact:

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

I’m using an example to illustrate that if Shaojie’s patch is accepted, other rules could be relaxed
following the same logic—but I’m not in favor of doing so.

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

-- 
Best regards,
Ridong