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

["Zhou, Yun" <yun.zhou@windriver.com>]

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