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

[Eric Dumazet]

On Tue, Aug 25, 2026 at 3:26 PM Shin'ichiro Kawasaki
<shinichiro.kawasaki@xxxxxxx> wrote:
>
> On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> > On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> > > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> > > >
> > > > I think 19bdb70c77d3 should be reverted.
> > >
> > > Just reverting the commit will reintroduce the other lockdep WARN that the
> > > commit addressed. I hope to have another fix to avoid the WARN.
> > >
> > I do not think you know the root cause of that lockdep warn, so reverting
> > 19bdb70c77d3 is the right thing to do because of [11, 12].
> >
> > [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> > [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> > https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@xxxxxxxx/
>
> I took a look in the commit [11] and the discussion [12], but couldn't follow
> why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> about the reason you suggest the revert?

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.

Use my pending TCP patch, which is a no brainer :
https://lore.kernel.org/netdev/20260825023614.1228551-1-edumazet@xxxxxxxxxx/

Revert 19bdb70c77d3 in drivers/nvme/host/tcp.c : Restore static
lockdep keys nvme_tcp_sk_key[2] and nvme_tcp_slock_key[2].

And we should be good.

If you think each nvme-tcp socket MUST have its own LOCKDEP class,
please elaborate, because I have no idea
why this would be needed.