Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

[Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>]

Hi,

On Thu, 14 Jul 2016 15:12:07 +0200, hannes@stressinduktion.org wrote:
> I liked the fact that setting IPSKB_FORWARDED was only contained in
> vxlan and as such wouldn't have as much impact. It was more logically
> easy to review for me actually.

I agree here. It is rather safe and to the point.

I'm trying to exaust other alternatives because it has one potential
drawback: the name IPSKB_FORWARDED suggests ipv4 forwarding had
happened. Indeed, current setters of IPSKB_FORWARDED are ip_forward and
ip_mr_forward.

If we set IPSKB_FORWARDED in iptunnel_xmit, with packet not being ipv4
forwarded (e.g. bridged from some ingress device to a tunnel device), it
presents a nuance whose impact is yet to be determined.

For example, what about a packet that gets encapsulated and sent to a
multicast destination? The condition controlling mc loop-back in
ip_mc_output is affected by the flag.

> > Which ensures only the following conditions go to the expensive
> > skb_gso_validate_mtu:
> > 
> > 1. IPSKB_FORWARDED is on
> > 2. IPSKB_FORWARDED is off, but sk exists and gso_size is untrusted.
> >    Meaning: we have a packet arriving from higher layers (sk is set)
> >    with a gso_size out of host's control.
> 
> When can this really happen? In general we don't want to refragment gso
> skb's and I think we can only make an exception for vxlan or udp.

When IPSKB_FORWARDED is off, we'll get SKB_GSO_DODGY if packet
originally arrived from tap/macvtap/packet and it did NOT pass ipv4
forwarding (e.g bridges: tap0 to eth0 bridge, or tap0 to vxlan0 bridge).

The rationale: in the SKB_GSO_DODGY cases, the gso_size is given by
the user's virtio-net header, which is not in kernel's control.

This exactly resembles the usecase: tap0 gives packets with gso_size
unsuitable for encapsulation and segmentation. I have no control on
the source that gives those packets.

If (1) it does not make sense, or (2) considered too broad-spectrum to
asses, then we can go with the safer IPSKB_FORWARDED approach.

Let me know.

Regards,
Shmulik