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: <Z37TiId4rFkwc0Mc@slm.duckdns.org>
Date: Wed, 8 Jan 2025 09:35:36 -1000
From: Tejun Heo <tj@...nel.org>
To: 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

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.

-- 
tejun