From: Daniel Axtens <dja@axtens.net>
To: netdev@vger.kernel.org
Cc: Daniel Axtens <dja@axtens.net>
Subject: [PATCH 0/6]GSO_BY_FRAGS correctness improvements
Date: Wed, 28 Feb 2018 00:04:01 +1100 [thread overview]
Message-ID: <20180227130407.22498-1-dja@axtens.net> (raw)
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
next reply other threads:[~2018-02-27 13:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 13:04 Daniel Axtens [this message]
2018-02-27 13:04 ` [PATCH 1/6] net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len Daniel Axtens
2018-02-27 13:04 ` [PATCH 2/6] net: sched: tbf: handle GSO_BY_FRAGS case in enqueue Daniel Axtens
2018-02-27 13:04 ` [PATCH 3/6] net: xfrm: use skb_gso_validate_network_len() to check gso sizes Daniel Axtens
2018-02-27 13:04 ` [PATCH 4/6] net: make skb_gso_*_seglen functions private Daniel Axtens
2018-02-28 15:53 ` David Miller
2018-02-27 13:04 ` [PATCH 5/6] net: add and use helpers when adjusting gso_size Daniel Axtens
2018-02-28 15:56 ` David Miller
2018-02-28 16:21 ` Daniel Borkmann
2018-03-01 0:17 ` Daniel Axtens
2018-03-01 0:47 ` Daniel Borkmann
2018-02-27 13:04 ` [PATCH 6/6] net: filter: refuse to change gso_size of SCTP packets Daniel Axtens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180227130407.22498-1-dja@axtens.net \
--to=dja@axtens.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox