On Aug 25, 2026 / 14:44, 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.
> 
> > 
> > We can change TCP to use sk_gfp_mask(sk, GFP_ATOMIC) instead of
> > gfp_any() in tcp_disconnect()
> > 
> > This ensures tcp_disconnect() respects sk->sk_allocation = GFP_ATOMIC
> > and never acquires fs_reclaim under sk_lock.
> > 
> > WDYT?
> 
> Thanks for the idea. I did a quick trial with the idea.
> 
> Step 1:
>   I reverted the commit 19bdb70c77d3 from v7.2 kernel, and confirmed that
>   the blktests test case nvme/005 for tcp transport recreates the lockdep
>   WARN that includes fs_reclaim in its lock chain.
> 
> Step 2:
>   I created a patch to replace gfp_any() in tcp_disconnect() with GFP_ATOMIC
>   [1]. I applied this patch to the v7.2 based kernel that I used in the step 1.
>   I ran the test case nvme/005 on this kernel, and observed it still fails
>   with the lockdep WARN: fs_reclaim was still included in the lock chain.
> 
>     I think this is expected, since fs_reclaim dependency comes from CPU hotplug
>     bring-up context.
> 
> Based on this observation, I'm afraid that using GFP_ATOMIC in tcp_disconnect()
> won't work, unfortunately.
> 
> Another approach I can think of is to use sk->sk_destruct hook to unregister
> keys, so that the unregistraion happens after the all in-flight skbs complete.
> I will try this approach.

I created a patch that delay the lockdep key unregstration until sk desctruct,
and attached it to this e-mail. It applies to the recent Linus master branch tip
(git hash 818bebeb63dd). Eric, may I ask your comment on the patch and this fix
approach?

I think this approach will avoid the lockdep that syzbot reported. But I don't
know how to confirm it. Could you do the confimration ? (or let me know how to
do it).

This approach adds some complexity. If anyone has simpler solution, it will be
great.