linux-kernel - Re: [PATCH v4 1/1] 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: <20251119110443.1386951-1-sunshaojie@kylinos.cn>
Date: Wed, 19 Nov 2025 19:04:43 +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 v4 1/1] cpuset: relax the overlap check for cgroup-v2

Hi, Michal,

On Tue, 18 Nov 2025 18:52:24 +0100, Michal Koutný wrote:
>On Mon, Nov 17, 2025 at 09:57:08AM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
>> This patch ensures that for sibling cpusets A1 (exclusive) and B1
>> (non-exclusive), change B1 cannot affect A1's exclusivity.
>> 
>> for example. Assume a machine has 4 CPUs (0-3).
>> 
>>    root cgroup
>>       /    \
>>     A1      B1
>> 
>> Case 1:
>>  Table 1.1: Before applying the patch
>>  Step                                       | A1's prstate | B1'sprstate |
>>  #1> echo "0-1" > A1/cpuset.cpus            | member       | member      |
>>  #2> echo "root" > A1/cpuset.cpus.partition | root         | member      |
>>  #3> echo "0" > B1/cpuset.cpus              | root invalid | member      |
>> 
>> After step #3, A1 changes from "root" to "root invalid" because its CPUs
>> (0-1) overlap with those requested by B1 (0-3). However, B1 can actually
>> use CPUs 2-3(from B1's parent), so it would be more reasonable for A1 to
>> remain as "root."
>> 
>>  Table 1.2: After applying the patch
>>  Step                                       | A1's prstate | B1'sprstate |
>>  #1> echo "0-1" > A1/cpuset.cpus            | member       | member      |
>>  #2> echo "root" > A1/cpuset.cpus.partition | root         | member      |
>>  #3> echo "0" > B1/cpuset.cpus              | root         | member      |
>
>OK, this looks fine to me, based on this statement from the docs about
>cpuset.cpus.effective:
>
>>  subset of "cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus"
>>  can be granted.  In this case, it will be treated just like an empty
>>  "cpuset.cpus".
>
>I was likely confused by the eventual switch of B1 to root in your
>previous example.
>(Because if you continue, it should result in (after patch too):
>  #4> echo "root" > B1/cpuset.partition       | root invalid  | root invalid |
>and end state should be invariant wrt A1,B1 or B1,A1 config order.)

This patch is based on a version after v6.18.0-rc5.
Whether or not this patch is applied, modifications to cpuset.partition do not
affect the state of sibling partitions.

If continue, the result should be as follows:
 #4> echo "root" > B1/cpuset.partition       | root         | root invalid |

I've updated patch v5 with some new ideas and look forward to your feedback.

patch v5 : https://lore.kernel.org/cgroups/20251119105749.1385946-1-sunshaojie@kylinos.cn/

Thanks,
Sun Shaojie