Re: [PATCH -next] sched/isolation: Use static_branch_enable_cpuslocked() on housekeeping_update

[Waiman Long <llong@redhat.com>]

On 1/22/26 3:09 AM, Chen Ridong wrote:
> From: Chen Ridong <chenridong@huawei.com>
>
> The warning is observed:
>
>   WARNING: possible recursive locking detected
>   6.19.0-rc6-next-20260121 #1046 Not tainted
>   --------------------------------------------
>   test_cpuset_prs/686 is trying to acquire lock:
>   (cpu_hotplug_lock){++++}-{0:0}, at: static_key_enable+0xd/0x20
>
>   but task is already holding lock:
>   (cpu_hotplug_lock){++++}-{0:0}, at: cpuset_partition_write+0x72/0x10
>
>   other info that might help us debug this:
>    Possible unsafe locking scenario:
>
>          CPU0
>          ----
>     lock(cpu_hotplug_lock);
>     lock(cpu_hotplug_lock);
>
>    *** DEADLOCK ***
>
>    May be due to missing lock nesting notation
>
>   stack backtrace:
>   CPU: 11 UID: 0 PID: 686 Comm: test_cpuset_prs  6.19.0-rc6-next-20260121 #1
>   Call Trace:
>    <TASK>
>    dump_stack_lvl+0x82/0xd0
>    print_deadlock_bug+0x288/0x3c0
>    __lock_acquire+0x1506/0x27f0
>    lock_acquire+0xc8/0x2d0
>    ? static_key_enable+0xd/0x20
>    cpus_read_lock+0x3b/0xd0
>    ? static_key_enable+0xd/0x20
>    static_key_enable+0xd/0x20
>    housekeeping_update+0xe7/0x1b0
>    update_prstate+0x3f2/0x580
>    cpuset_partition_write+0x98/0x100
>    kernfs_fop_write_iter+0x14e/0x200
>    vfs_write+0x367/0x510
>    ksys_write+0x66/0xe0
>    do_syscall_64+0x6b/0x390
>    entry_SYSCALL_64_after_hwframe+0x76/0x7e
>   RIP: 0033:0x7f824cf8c887
>
> The commit 7109b22e6581 ("cpuset: Update HK_TYPE_DOMAIN cpumask from
> cpuset") introduced housekeeping_update, which calls static_branch_enable
> while cpu_read_lock() is held. Since static_key_enable itself also acquires
> cpu_read_lock, this leads to a lockdep warning. To resolve this issue,
> replace the call to static_key_enable with static_branch_enable_cpuslocked.
>
> Fixes: 7109b22e6581 ("cpuset: Update HK_TYPE_DOMAIN cpumask from cpuset")
> Signed-off-by: Chen Ridong <chenridong@huawei.com>
> ---
>   kernel/cgroup/cpuset.c   | 2 --
>   kernel/sched/isolation.c | 4 +++-
>   2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 392ce795656d..a26ccff55bb7 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1308,8 +1308,6 @@ static void update_isolation_cpumasks(void)
>   	if (!isolated_cpus_updating)
>   		return;
>   
> -	lockdep_assert_cpus_held();
> -
>   	ret = housekeeping_update(isolated_cpus);
>   	WARN_ON_ONCE(ret < 0);
>   
> diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> index ef152d401fe2..3b725d39c06e 100644
> --- a/kernel/sched/isolation.c
> +++ b/kernel/sched/isolation.c
> @@ -123,6 +123,8 @@ int housekeeping_update(struct cpumask *isol_mask)
>   	struct cpumask *trial, *old = NULL;
>   	int err;
>   
> +	lockdep_assert_cpus_held();
> +
>   	trial = kmalloc(cpumask_size(), GFP_KERNEL);
>   	if (!trial)
>   		return -ENOMEM;
> @@ -134,7 +136,7 @@ int housekeeping_update(struct cpumask *isol_mask)
>   	}
>   
>   	if (!housekeeping.flags)
> -		static_branch_enable(&housekeeping_overridden);
> +		static_branch_enable_cpuslocked(&housekeeping_overridden);
>   
>   	if (housekeeping.flags & HK_FLAG_DOMAIN)
>   		old = housekeeping_cpumask_dereference(HK_TYPE_DOMAIN);

Good catch.

Thanks,
Longman