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

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

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:
>>> 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:
> 

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.