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: <c01767cc-9f8b-4331-8928-9de97b430cf4@huaweicloud.com>
Date: Thu, 22 Jan 2026 20:03:56 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Frederic Weisbecker <frederic@...nel.org>
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



On 2026/1/22 19:45, Frederic Weisbecker wrote:
> 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.
> 

I'm not entirely clear on the specifics of "breaking bisection", never mind, I
trust your judgment. Please go ahead and fix it in the way that you like.

-- 
Best regards,
Ridong