Re: [PATCH/for-next v3 2/3] cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue

[Waiman Long <llong@redhat.com>]

On 2/2/26 3:48 PM, Peter Zijlstra wrote:
> On Mon, Feb 02, 2026 at 03:32:03PM -0500, Waiman Long wrote:
>> On 2/2/26 3:18 PM, Peter Zijlstra wrote:
>>> On Mon, Feb 02, 2026 at 03:11:43PM -0500, Waiman Long wrote:
>>>
>>>> @@ -1310,14 +1321,34 @@ static bool prstate_housekeeping_conflict(int prstate, struct cpumask *new_cpus)
>>>>     */
>>>>    static void update_isolation_cpumasks(void)
>>>>    {
>>>> -	int ret;
>>>> +	static DECLARE_WORK(isolcpus_work, isolcpus_workfn);
>>>>    	if (!isolated_cpus_updating)
>>>>    		return;
>>>> -	ret = housekeeping_update(isolated_cpus);
>>>> -	WARN_ON_ONCE(ret < 0);
>>>> +	/*
>>>> +	 * This function can be reached either directly from regular cpuset
>>>> +	 * control file write or via CPU hotplug. In the latter case, it is
>>>> +	 * the per-cpu kthread that calls cpuset_handle_hotplug() on behalf
>>>> +	 * of the task that initiates CPU shutdown or bringup.
>>>> +	 *
>>>> +	 * To have better flexibility and prevent the possibility of deadlock
>>>> +	 * when calling from CPU hotplug, we defer the housekeeping_update()
>>>> +	 * call to after the current cpuset critical section has finished.
>>>> +	 * This is done via workqueue.
>>>> +	 */
>>>> +	if (current->flags & PF_KTHREAD) {
>>> 		/* Serializes the static isolcpus_workfn. */
>>> 		lockdep_assert_held(&cpuset_mutex);
>> Do we require synchronization between the the queue_work() call and the
>> execution of the work function? I thought it is not needed, but I may be
>> wrong.
> Well, something needs to ensure there aren't two threads trying to use
> this one work thing at the same time, no?

isolcpus_workfn() does touches the work struct and there can't be more 
than one thread calling queue_work() with the same work. However it is 
possible that if isolcpus_workfn() and this code path are completely 
async, there is a chance that we may miss a call to 
housekeeping_update(). So I need to take a further look into that.

Cheers,
Longman