linux-kernel - Re: [PATCH v2] cgroup/cpuset: remove kernfs active break

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: <625d03cd-302f-41b1-9502-dfd25eb677e1@redhat.com>
Date: Wed, 8 Jan 2025 14:50:19 -0500
From: Waiman Long <llong@...hat.com>
To: Tejun Heo <tj@...nel.org>, Waiman Long <llong@...hat.com>
Cc: Chen Ridong <chenridong@...weicloud.com>, hannes@...xchg.org,
 mkoutny@...e.com, cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] cgroup/cpuset: remove kernfs active break


On 1/8/25 2:35 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 08, 2025 at 02:27:07PM -0500, Waiman Long wrote:
>> On 1/8/25 11:53 AM, Tejun Heo wrote:
>> This patch looks good me. However, this does raise a question that I
>> overlook when I made hotplug operation synchronous while task transfer, if
>> needed, remained asynchronous. There is a very slight chance where we keep
>> removing tasks added after execution capability is restored. As cgroup v1 is
>> in the process of being deprecated, do you think we still need to do
>> something to address this issue?
> I *think* that should be fine. In cgroup1, the kernel is making irreversible
> system config changes when a cgroup loses all its CPUs. I have a hard time
> imagining use cases that would depend on the the exact ordering of
> operations at that point. The auto transfer-out was always the last ditch
> measure to not leave the system in a broken state after all. If someone's
> depending on the transfer out being strictly ordered w.r.t. the cgroup
> losing all CPUs and then gaining some, let's hear why the hell that ordering
> matters first.

Thanks for the explanation.

It is not the strict ordering that I am worrying about. It is all about 
the possibility of hitting some race conditions.

I am thinking of a scenario where a cpuset loses all its CPUs in 
hotunplug and then restored by adding other CPUs. There is chance that 
the css will be operated on concurrently by the auto-transfer task and 
another task moving new task to the css. I am not sure if that will be a 
problem or not. Anyway, it is very rare that we will be in such a situation.

Thanks,
Longman