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: <37f4b54d-609c-4754-bfa2-51b1ddf43df0@huaweicloud.com>
Date: Thu, 20 Nov 2025 21:25:12 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Sun Shaojie <sunshaojie@...inos.cn>
Cc: cgroups@...r.kernel.org, hannes@...xchg.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 llong@...hat.com, mkoutny@...e.com, shuah@...nel.org, tj@...nel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on
 cpuset.cpus conflict.



On 2025/11/20 21:07, Sun Shaojie wrote:
> Hi, Ridong,
> 
> On Thu, 20 Nov 2025 08:57:51, Chen Ridong wrote:
>> On 2025/11/19 21:20, Michal Koutný wrote:
>>> On Wed, Nov 19, 2025 at 06:57:49PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
>>>>  Table 2.1: Before applying this patch
>>>>  Step                                       | A1's prstate | B1's prstate |
>>>>  #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>>>>  #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>>>>  #3> echo "2" > B1/cpuset.cpus              | root         | member       |
>>>>  #4> echo "root" > B1/cpuset.cpus.partition | root         | root         |
>>>>  #5> echo "1-2" > B1/cpuset.cpus            | root invalid | root invalid |
>>>>
>>>> After step #4, B1 can exclusively use CPU 2. Therefore, at step #5,
>>>> regardless of what conflicting value B1 writes to cpuset.cpus, it will
>>>> always have at least CPU 2 available. This makes it unnecessary to mark
>>>> A1 as "root invalid".
>>>>
>>>>  Table 2.2: After applying this patch
>>>>  Step                                       | A1's prstate | B1's prstate |
>>>>  #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>>>>  #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>>>>  #3> echo "2" > B1/cpuset.cpus              | root         | member       |
>>>>  #4> echo "root" > B1/cpuset.cpus.partition | root         | root         |
>>>>  #5> echo "1-2" > B1/cpuset.cpus            | root         | root invalid |
>>>>
>>>> In summary, regardless of how B1 configures its cpuset.cpus, there will
>>>> always be available CPUs in B1's cpuset.cpus.effective. Therefore, there
>>>> is no need to change A1 from "root" to "root invalid".
>>>
>>> Admittedly, I don't like this change because it relies on implicit
>>> preference ordering between siblings (here first comes, first served)
>>
>> Agree. If we only invalidate the latter one, I think regardless of the implementation approach, we
>> may end up with different results depending on the order of operations.
> 
> 
> I don't understand the "order of operations" mentioned here. After reviewing
> the previous email content, are you referring to this?
> 
> On Sat, 15 Nov 2025 15:41:03, Chen Ridong wrote:
>> With the result you expect, would we observe the following behaviors:
>>
>> #1> mkdir -p A1
>> #2> mkdir -p B1
>> #3> echo "0-1"  > A1/cpuset.cpus
>> #4> echo "1-2"  > B1/cpuset.cpus
>> #5> echo "root" > A1/cpuset.cpus.partition
>> #6> echo "root" > B1/cpuset.cpus.partition # A1:root;B1:root invalid
>>
>> #1> mkdir -p A1
>> #2> mkdir -p B1
>> #3> echo "0-1"  > A1/cpuset.cpus
>> #4> echo "1-2"  > B1/cpuset.cpus
>> #5> echo "root" > B1/cpuset.cpus.partition
>> #6> echo "root" > A1/cpuset.cpus.partition # A1:root invalid;B1:root
>>
>> Do different operation orders yield different results? If so, this is not what we expect.
> 
> However, after applying this patch, the outcomes of these two examples are 
> as follows:
>  
>  #1> mkdir -p A1
>  #2> mkdir -p B1
>  #3> echo "0-1"  > A1/cpuset.cpus           | member       | member      |
>  #4> echo "1-2"  > B1/cpuset.cpus           | member       | member      |
>  #5> echo "root" > A1/cpuset.cpus.partition | root invalid | root        |
>  #6> echo "root" > B1/cpuset.cpus.partition | root invalid | root invalid|
> 
>  #1> mkdir -p A1
>  #2> mkdir -p B1
>  #3> echo "0-1"  > A1/cpuset.cpus           | member       | member      |
>  #4> echo "1-2"  > B1/cpuset.cpus           | member       | member      |
>  #5> echo "root" > B1/cpuset.cpus.partition | root         | root invalid|
>  #6> echo "root" > A1/cpuset.cpus.partition | root invalid | root invalid|
> 

How about the following two sequences of operations:

#1> mkdir -p A1
#2> mkdir -p B1
#3> echo "0-1"  > A1/cpuset.cpus
#4> echo "root" > A1/cpuset.cpus.partition
#5> echo "1-2"  > B1/cpuset.cpus
#6> echo "root" > B1/cpuset.cpus.partition


#1> mkdir -p A1
#2> mkdir -p B1
#5> echo "1-2"  > B1/cpuset.cpus
#6> echo "root" > B1/cpuset.cpus.partition
#3> echo "0-1"  > A1/cpuset.cpus
#4> echo "root" > A1/cpuset.cpus.partition

Will these two sequences yield the same result?

As a key requirement: Regardless of the order in which we apply the configurations, identical final
settings should always result in identical system states. We need to confirm if this holds true here.

> Moreover, even without applying this patch, the result remains the same,
> because modifying cpuset.cpus.partition does not disable its siblings' partitions.
> 
> So, what are the specific issues that you believe would arise?
> 
> 
> Thanks,
> Sun Shaojie

-- 
Best regards,
Ridong