Re: [PATCH net v4] net: erspan: set lltx to avoid sch_direct_xmit deadlock

[Zhou, Yun]

On 9/16/26 16:20, Ido Schimmel wrote:
> On Wed, Sep 16, 2026 at 02:13:14PM +0800, Yun Zhou wrote:
> > erspan_xmit() re-enters the network stack via ip_tunnel_xmit(), causing
> > nested acquisition of _xmit_lock on the underlay device while already
> > holding the ERSPAN device's _xmit_lock, creating an ABBA deadlock:
> >
> >    sch_direct_xmit [lock erspan] -> erspan_xmit -> ip_tunnel_xmit ->
> >    ip_output -> __dev_queue_xmit -> sch_direct_xmit [lock underlay]
> >
> > Set dev->lltx = true so HARD_TX_LOCK() skips the spinlock for ERSPAN.
> > This is safe as erspan_xmit() has no shared mutable state: o_seqno is
> > atomic, TX stats are per-CPU u64_stats, dst_cache is per-CPU, and
> > o_flags is no longer modified in the xmit path since commit 9958e69b9893
> > ("gre: fix ERSPAN o_flags race/corruption in xmit and fill_info").
> > GRETAP, the sibling device with identical xmit structure, already sets
> > lltx.
>
> In v3 I asked that the commit message:
>
> 1. State that the overlay and underlay devices should be of the same
> type (both erspan or both ip6erspan) for the splat to happen.
The devices do not need to be the same type. The actual syzbot report 
[1] is between IPv4 erspan and vti6 - two completely different tunnel types:

  -> #1: erspan_xmit (net/ipv4/ip_gre.c)   holding &qdisc_xmit_lock_key#2
  -> #0: vti6_tnl_xmit (net/ipv6/ip6_vti.c) holding &qdisc_xmit_lock_key#3

I can reproduce this reliably with erspan <-> vti6 cross-routed in a 
netns (no same-type stacking involved).

Additionally, I think it makes sense to set lltx=true for vti6 as well.

[1] https://syzkaller.appspot.com/text?tag=CrashReport&x=15b29287180000

Thanks,
Yun