Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler

[Hillf Danton]

On Wed, 26 Aug 2026 11:23:37 +0900 Shin'ichiro Kawasaki wrote:
>On Aug 25, 2026 / 16:27, Eric Dumazet wrote:
>> On Tue, Aug 25, 2026 at 3:53 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
>> > I think you missed one problem in lib/once.c
>> >
>> > Revert commit e8eef69a99f1 (or restore once_disable_jump(once_key,
>> > mod) inside __do_once_sleepable_done())
>> > so static_branch_disable() is never called synchronously under caller locks.
>> >
>> > Previously, once_disable_jump() deferred static_branch_disable() to a
>> > worker thread via schedule_work().
>> >
>> > Commit e8eef69a99f1 made it run synchronously in the caller's context.
>> > Because __inet_hash_connect() is called under lock_sock(sk), calling
>> > static_branch_disable() directly inside DO_ONCE_SLEEPABLE() takes
>> > cpus_read_lock() (cpu_hotplug_lock) while holding lock_sock(sk).
>> >
>> > This created the bogus lock dependency sk_lock -> cpu_hotplug_lock.
>> >
>> > Every other storage/networking client (sunrpc, nbd, cifs, iscsi_tcp,
>> > rxe, siw) uses static lockdep keys (static struct lock_class_key
>> > ...[2]) without issue.
>> 
>> I  sent the revert request for review :
>> https://lore.kernel.org/lkml/20260825142515.1965654-1-edumazet@xxxxxxxxxx/T/#u
>
> Thank you for the clarification. Now I have better understanding.
> 
> When I looked at the lock dependency chain among six locks below, I assumed
> that any of the dependencies could not be cut.
> 
>    set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu
> 
> So I thought that the idea to introduce the dynamic lockdep key for nvme-tcp
> sk_lock instances would be the only one solution. But you pointed out that the
> dependency sk_lock -> cpu_hotplug_lock can be cut by reverting the commit
> e8eef69a99f1.
> 
> I did trial and confirmed that your suggestion works. With the kerenl v7.2 +
> revert 19bdb70c77d3 + revert e8eef69a99f1, I confirmed the blktests test case
> nvme/005 passed with tcp transport. The lockdep WARN due to the six locks goes
> away. Great :)
>
Reverting e8eef69a99f1 alone failed to survive the syzbot test [15].
Nor did Eric's change [16] to lockdep alone [17].
Nor did Eric's change [16] to lockdep after Reverting e8eef69a99f1 [18].

[15] Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
https://lore.kernel.org/lkml/6a90125e.1d9ded08.62e62.00d0.GAE@xxxxxxxxxx/

[16] Subject: [PATCH] locking/lockdep: Invalidate stale class_cache entries for zapped classes
https://lore.kernel.org/lkml/20260824155129.676096-1-edumazet@xxxxxxxxxx/

[17] Subject: Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
https://lore.kernel.org/lkml/6a8fa86e.27659fcc.2ceef7.000c.GAE@xxxxxxxxxx/

[18] Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
https://lore.kernel.org/lkml/6a8fd74f.4d659fcc.734b4.000c.GAE@xxxxxxxxxx/

WTF root cause is Eric attempting to fix?