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: <20251124102118.1768596-1-sunshaojie@kylinos.cn>
Date: Mon, 24 Nov 2025 18:21:18 +0800
From: Sun Shaojie <sunshaojie@...inos.cn>
To: chenridong@...weicloud.com
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,
	sunshaojie@...inos.cn,
	tj@...nel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict.

Hi, Ridong,

On Sat, 22 Nov 2025 09:19:39, Chen Ridong wrote:
>On 2025/11/21 18:33, Sun Shaojie wrote:
>> Is this truly a key requirement? It appears this requirement wasn't met even
>> before applying my patch.
>> 
>
>I believe it requires, it may some corner cases we should fix.
>
>> The example below, which does not use this patch, demonstrates how different
>> sequences with identical configurations can still lead to different system
>> states.
>> 
>>  #1> mkdir -p A1
>>  #2> mkdir -p B1                            | A1's prstate | B1's prstate |
>>  #3> echo "0-1"  > A1/cpuset.cpus           | member       | member       |
>>  #4> echo "0-1"  > A1/cpuset.cpus.exclusive | member       | member       |
>>  #5> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>>  #6> echo "1-2"  > B1/cpuset.cpus           | root invalid | member       |
>>  #7> echo "2-3"  > B1/cpuset.cpus.exclusive | root invalid | member       |
>>  #8> echo "root" > B1/cpuset.cpus.partition | root invalid | root         |
>> 
>
>IIUC, you've created this example with the expectation that both A1 and B1 should serve as root
>partitions. However, we currently lack a mechanism where modifying a cpuset's state (e.g., cpus,
>cpus.exclusive, or cpus.partition) can transition its sibling from an invalid to a valid partition.
>
>The behavior observed before step #6 is acceptable. Proactively setting B1 as a partition in step #8
>is permitted, given that B1 does not conflict with A1. However, we do not have a mechanism to
>passively and automatically transition A1 to a valid partition state.
>

So, was the original behavior of invalidating sibling partitions driven by this key requirement?
(As a key requirement: Regardless of the order in which we apply the configurations, identical final
settings should always result in identical system states.)

>>  #1> mkdir -p A1
>>  #2> mkdir -p B1                            | A1's prstate | B1's prstate |
>>  #3> echo "0-1"  > A1/cpuset.cpus           | member       | member       |
>>  #4> echo "0-1"  > A1/cpuset.cpus.exclusive | member       | member       |
>>  #5> echo "2-3"  > B1/cpuset.cpus.exclusive | member       | member       |
>>  #6> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>>  #7> echo "1-2"  > B1/cpuset.cpus           | root         | member       |
>>  #8> echo "root" > B1/cpuset.cpus.partition | root         | root         |
>> 
>> Even without this patch, the result can still differ.
>> 

Thanks,
Sun Shaojie

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ