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

On 9/16/26 16:20, Ido Schimmel wrote:

On Wed, Sep 16, 2026 at 02:13:14PM +0800, Yun Zhou wrote:

quoted

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