Request: follow-up fixes for "net: add xmit recursion limit to tunnel xmit functions" in 6.6.y and 6.1.y

[Ting-Han Hou <ue081723@gmail.com>]

Hi Greg, Sasha,

6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit
functions") was backported to 6.6.y in 6.6.160 and is currently in
queue-6.1, but two upstream follow-up fixes for it were not. Please
consider queueing:

For 6.6.y:

  c38b8f5f791e ("net: prevent NULL deref in ip[6]tunnel_xmit()")
  77facb35227c ("net: increase IP_TUNNEL_RECURSION_LIMIT to 5")

For 6.1.y (on top of the queued 6f1a9140ecda backport):

  77facb35227c ("net: increase IP_TUNNEL_RECURSION_LIMIT to 5")

The queued 6.1 backport of 6f1a9140ecda already includes the
"if (dev)" check from c38b8f5f791e, so only the limit change is
missing there.

Why:

- 77facb35227c: with a limit of 4, setups with multiple tunnel
  layers and MPLS lwtunnel routing drop legitimate packets with
  "Dead loop on virtual device ..." even though there is no loop.
  6.6.160 now has this regression, and 6.1 will get it with the
  queued backport. Upstream raised the limit to 5; it is in 6.12.83,
  6.18.24 and 6.19.14.

- c38b8f5f791e: iptunnel_xmit() and ip6tunnel_xmit() can be called
  with dev == NULL (e.g. SCTP and TIPC over UDP), and the new
  recursion check dereferences dev when the limit is hit. It is in
  6.12.78, 6.18.19 and 6.19.9.

Both commits cherry-pick cleanly onto v6.6.160, and 77facb35227c
cherry-picks cleanly onto v6.1.190 plus queue-6.1 (stable-queue
fa04d3db75). I build-tested the affected objects (ip_tunnel_core,
ip_tunnel, ip6_tunnel, ip6_udp_tunnel, the GRE/IPIP/SIT, VXLAN,
Geneve, bareudp and GTP drivers, SCTP and TIPC UDP media) with W=1
on both trees, with no new warnings. I did not do runtime testing.

I noticed the gap while checking which stable trees carry
77facb35227c.

Thanks,
Ting-Han Hou