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

On Wed, 26 Aug 2026 11:23:37 +0900 Shin'ichiro Kawasaki wrote:

On Aug 25, 2026 / 16:27, Eric Dumazet wrote:

quoted

On Tue, Aug 25, 2026 at 3:53 PM Eric Dumazet [off-list ref] wrote:

quoted

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@google.com/T/#u (local)

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@google.com/ (local)

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

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

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

WTF root cause is Eric attempting to fix?