Re: [PATCH/for-next v2 1/2] cgroup/cpuset: Defer housekeeping_update() call from CPU hotplug to workqueue

From: Waiman Long

Date: Mon Feb 02 2026 - 13:25:33 EST


On 2/2/26 8:05 AM, Peter Zijlstra wrote:
On Fri, Jan 30, 2026 at 10:42:53AM -0500, Waiman Long wrote:

+/* Both cpuset_mutex and cpus_read_locked acquired */
+static bool cpuset_locked;
+
/*
* A flag to force sched domain rebuild at the end of an operation.
* It can be set in
@@ -285,10 +288,12 @@ void cpuset_full_lock(void)
{
cpus_read_lock();
mutex_lock(&cpuset_mutex);
+ cpuset_locked = true;
}
void cpuset_full_unlock(void)
{
+ cpuset_locked = false;
mutex_unlock(&cpuset_mutex);
cpus_read_unlock();
}
@@ -1293,14 +1308,30 @@ 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 (cpuset_locked) or via hotplug (cpus_write_lock
+ * && cpuset_mutex held). In the later case, we defer the
+ * housekeeping_update() call to the system_unbound_wq to avoid the
+ * possibility of deadlock. This also means that there will be a short
+ * period of time where HK_TYPE_DOMAIN housekeeping cpumask will lag
+ * behind isolated_cpus.
+ */
+ if (!cpuset_locked) {
I agree with Chen that this is bloody terrible.

At the very least this should have:

lockdep_assert_held(&cpuset_mutex);

But ideally you'd do patches against this and tip/locking/core that add
proper __guarded_by() annotations to this.

Yes, I am going to remove cpuset_locked in the next version. As for __guarded_by() annotation, I need to set up a clang environment that I can use to test it before I will work on that. I usually just use gcc for my compilation need.

Cheers,
Longman