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
