[REGRESSION] net: add xmit recursion limit to tunnel xmit functions

[REGRESSION] net: add xmit recursion limit to tunnel xmit functions

[Chris Arges]

Hello,

Commit 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
introduces a regression in our systems using legitimate multi-level tunnel
encapsulation stacks. Our testing was with stable 6.12.y and 6.18.y where this
patch was backported.

One of the usecases we have are packets being sent to a GRE device, then
MPLS/LWT route, then IPIP device, then SIT/FOU device. What we observed is that
packets are getting dropped at the last device and we get the message "Dead
loop on virtual device" sent from the iptunnel_xmit function.

I'm looking for some approaches to retain the mitigation while still having a
recursion limit. One idea is to just increase the limit. Happy to provide
additional testing and debugging.

Thanks,
--chris

Re: [REGRESSION] net: add xmit recursion limit to tunnel xmit functions

[Jakub Kicinski]

On Tue, 31 Mar 2026 15:09:33 -0500 Chris Arges wrote:
> Commit 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
> introduces a regression in our systems using legitimate multi-level tunnel
> encapsulation stacks. Our testing was with stable 6.12.y and 6.18.y where this
> patch was backported.
> 
> One of the usecases we have are packets being sent to a GRE device, then
> MPLS/LWT route, then IPIP device, then SIT/FOU device. What we observed is that
> packets are getting dropped at the last device and we get the message "Dead
> loop on virtual device" sent from the iptunnel_xmit function.

Last device meaning limit of 5 would have worked for you?
I don't think there was any hard math behind the 4 so ++
on the limit may be simplest, but I defer to Paolo..

Re: [REGRESSION] net: add xmit recursion limit to tunnel xmit functions

[Paolo Abeni]

On 4/2/26 2:38 AM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 15:09:33 -0500 Chris Arges wrote:
>> Commit 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
>> introduces a regression in our systems using legitimate multi-level tunnel
>> encapsulation stacks. Our testing was with stable 6.12.y and 6.18.y where this
>> patch was backported.
>>
>> One of the usecases we have are packets being sent to a GRE device, then
>> MPLS/LWT route, then IPIP device, then SIT/FOU device. What we observed is that
>> packets are getting dropped at the last device and we get the message "Dead
>> loop on virtual device" sent from the iptunnel_xmit function.
> 
> Last device meaning limit of 5 would have worked for you?
> I don't think there was any hard math behind the 4 so ++
> on the limit may be simplest, but I defer to Paolo..

AFAICS the '4' limit was an empirical choice, and the reported splat
used 7 devices, so moving to 5 should fit, even if I must admit it feels
a bit a whack a mole situation. On the flip side a revert of the blamed
commit feels not safe.

@Chris, could you please share a patch increasing the limit to 5?

Thanks,

Paolo