linux-kernel - Re: [PATCH -next] sched/isolation: Use static_branch_enable_cpuslocked() on housekeeping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXIN45kR5_PQgtK2@localhost.localdomain>
Date: Thu, 22 Jan 2026 12:45:39 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Chen Ridong <chenridong@...weicloud.com>
Cc: longman@...hat.com, tj@...nel.org, hannes@...xchg.org, mkoutny@...e.com,
	mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, lujialin4@...wei.com
Subject: Re: [PATCH -next] sched/isolation: Use
 static_branch_enable_cpuslocked() on housekeeping_update

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