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

[Frederic Weisbecker <frederic@kernel.org>]

Le Thu, Jan 22, 2026 at 08:09:02AM +0000, Chen Ridong a écrit :
> 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>

Thanks for spotting that! Funny that it didn't deadlock when I tested it.
Ah probably because I always booted with isolcpus= filled.

So ideally I should add your change as a fixup within
7109b22e6581 ("cpuset: Update HK_TYPE_DOMAIN cpumask from cpuset") in order
not to break bisection.

Do you mind if I do that? I'll still add your Signed-off-by to the commit.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs