Re: [PATCH net v4] net: erspan: set lltx to avoid sch_direct_xmit deadlock
From: Zhou, Yun
Date: Sat Sep 19 2026 - 23:02:33 EST
On 9/20/26 10:48, Zhou, Yun wrote:
On 9/16/26 16:20, Ido Schimmel wrote:
On Wed, Sep 16, 2026 at 02:13:14PM +0800, Yun Zhou wrote: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:
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.
More precisely, any pair of 'locked + re-entering' tunnel devices whose
underlying paths intersect could trigger this issue — for example,
gre{6} (which previously didn't have lltx set correctly), and currently
erspan{6}, vti6, etc. Same-type pairing is just one possible
combination, not a requirement.