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

[Waiman Long <llong@redhat.com>]

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