[PATCH 0/6]GSO_BY_FRAGS correctness improvements

* [PATCH 0/6]GSO_BY_FRAGS correctness improvements
@ 2018-02-27 13:04 Daniel Axtens
  2018-02-27 13:04 ` [PATCH 1/6] net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len Daniel Axtens
                   ` (5 more replies)
  0 siblings, 6 replies; 12+ messages in thread
From: Daniel Axtens @ 2018-02-27 13:04 UTC (permalink / raw)
  To: netdev; +Cc: Daniel Axtens

As requested [1], I went through and had a look at users of gso_size to
see if there were things that need to be fixed to consider
GSO_BY_FRAGS, and I have tried to improve our helper functions to deal
with this case.

I found a few, and this fixes all but one of them. The one thing that
remains is qdisc_pkt_len_init which is discussed at [2] - it's caught
up in the GSO_DODGY mess. I don't have any expertise in GSO_DODGY, and
it looks like a good clean fix will involve unpicking the whole
validation mess, so I have left it for now.

Patch 1 renames skb_gso_validate_mtu to skb_gso_validate_network_len.
This is follow-up to my earlier patch 2b16f048729b ("net: create
skb_gso_validate_mac_len()"), and just makes everything a bit clearer.

Patches 2 and 3 replace the final users of skb_gso_network_seglen() -
which doesn't consider GSO_BY_FRAGS - with
skb_gso_validate_network_len(), which does. This allows me to make the
skb_gso_*_seglen functions private in patch 4 - now future users won't
accidentally do the wrong comparison.

Lastly, there are 3 eBPF opcodes that change the gso_size of an SKB
and don't consider GSO_BY_FRAGS. To address this, patch 5 adds a
couple of helpers for changing gso_size that throw a WARN if you use
them on a GSO_BY_FRAGS packet. To return a useful error to eBPF, patch
6 goes further and prevents any change of gso_size for SCTP GSO skbs.

Regards,
Daniel

[1] https://patchwork.ozlabs.org/comment/1852414/
[2] https://www.spinics.net/lists/netdev/msg482397.html

PS: This is all in the core networking stack. For a driver to be
affected by this it would need to support NETIF_F_GSO_SCTP /
NETIF_F_GSO_SOFTWARE and then either use gso_size or not be a purely
virtual device. (Many drivers look at gso_size, but do not support
SCTP segmentation, so the core network will segment an SCTP gso before
it hits them.) Based on that, the only driver that may be affected is
sunvnet, but I have no way of testing it, so I haven't looked at it.

Daniel Axtens (6):
  net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len
  net: sched: tbf: handle GSO_BY_FRAGS case in enqueue
  net: xfrm: use skb_gso_validate_network_len() to check gso sizes
  net: make skb_gso_*_seglen functions private
  net: add and use helpers when adjusting gso_size
  net: filter: refuse to change gso_size of SCTP packets

 Documentation/networking/segmentation-offloads.txt | 11 ++++-
 include/linux/skbuff.h                             | 51 ++++++++--------------
 net/core/filter.c                                  | 24 ++++++++--
 net/core/skbuff.c                                  | 48 +++++++++++++++++---
 net/ipv4/ip_forward.c                              |  2 +-
 net/ipv4/ip_output.c                               |  2 +-
 net/ipv4/netfilter/nf_flow_table_ipv4.c            |  2 +-
 net/ipv4/xfrm4_output.c                            |  3 +-
 net/ipv6/ip6_output.c                              |  2 +-
 net/ipv6/netfilter/nf_flow_table_ipv6.c            |  2 +-
 net/ipv6/xfrm6_output.c                            |  2 +-
 net/mpls/af_mpls.c                                 |  2 +-
 net/sched/sch_tbf.c                                |  3 +-
 net/xfrm/xfrm_device.c                             |  2 +-
 14 files changed, 99 insertions(+), 57 deletions(-)

-- 
2.14.1

^ permalink raw reply	[flat|nested] 12+ messages in thread