netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Daniel Axtens <dja@axtens.net>
Cc: netdev@vger.kernel.org, Manish.Chopra@cavium.com, dev@openvswitch.org
Subject: Re: [PATCH 2/3] net: is_skb_forwardable: validate length of GSO packet segments
Date: Thu, 18 Jan 2018 21:47:38 -0200	[thread overview]
Message-ID: <20180118234737.GA3502@localhost.localdomain> (raw)
In-Reply-To: <20180116020920.20232-3-dja@axtens.net>

On Tue, Jan 16, 2018 at 01:09:19PM +1100, Daniel Axtens wrote:
> is_skb_forwardable attempts to detect if a packet is too large to
> be sent to the destination device. However, this test does not
> consider GSO packets, and it is possible that a GSO packet, when
> resegmented, will be larger than the device can transmit.
> 
> Add detection for packets which will be too large by creating a
> skb_gso_validate_len() routine which is similar to
> skb_gso_validate_mtu(), but which considers L2 headers, and wire

Why not add a 3rd parameter to skb_gso_validate_mtu() instead, hlen?
After all it's the only difference between both.

And maybe rename _mtu if you think the term doesn't fit in the new
usecase or add a wrapper around it for each case.

As it is here, it gets very confusing on which function does what,
IMHO.

> it up in is_skb_forwardable().
> 
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
>  include/linux/skbuff.h |  1 +
>  net/core/dev.c         |  7 ++++---
>  net/core/skbuff.c      | 34 ++++++++++++++++++++++++++++++++++
>  3 files changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index b8acafd73272..6a9e4b6f80a7 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3287,6 +3287,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen);
>  void skb_scrub_packet(struct sk_buff *skb, bool xnet);
>  unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
>  bool skb_gso_validate_mtu(const struct sk_buff *skb, unsigned int mtu);
> +bool skb_gso_validate_len(const struct sk_buff *skb, unsigned int len);
>  struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
>  struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
>  int skb_ensure_writable(struct sk_buff *skb, int write_len);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 94435cd09072..5af04be128c1 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1841,11 +1841,12 @@ bool is_skb_forwardable(const struct net_device *dev, const struct sk_buff *skb)
>  	if (skb->len <= len)
>  		return true;
>  
> -	/* if TSO is enabled, we don't care about the length as the packet
> -	 * could be forwarded without being segmented before
> +	/*
> +	 * if TSO is enabled, we need to check the size of the
> +	 * segmented packets
>  	 */
>  	if (skb_is_gso(skb))
> -		return true;
> +		return skb_gso_validate_len(skb, len);
>  
>  	return false;
>  }
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 01e8285aea73..aefe049e4b0c 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -4945,6 +4945,40 @@ bool skb_gso_validate_mtu(const struct sk_buff *skb, unsigned int mtu)
>  }
>  EXPORT_SYMBOL_GPL(skb_gso_validate_mtu);
>  
> +/**
> + * skb_gso_validate_len - Will a split GSO skb fit in a given length?
> + *
> + * @skb: GSO skb
> + * @len: length to validate against
> + *
> + * skb_gso_validate_len validates if a given skb will fit a wanted
> + * length once split, including L2, L3 and L4 headers.
> + *
> + * Similar to skb_gso_validate_mtu, but inclusive of L2 headers.
> + */
> +bool skb_gso_validate_len(const struct sk_buff *skb, unsigned int len)
> +{
> +	const struct skb_shared_info *shinfo = skb_shinfo(skb);
> +	const struct sk_buff *iter;
> +	unsigned int hlen;
> +
> +	hlen = skb_gso_mac_seglen(skb);
> +
> +	if (shinfo->gso_size != GSO_BY_FRAGS)
> +		return hlen <= len;
> +
> +	/* Undo this so we can re-use header sizes */
> +	hlen -= GSO_BY_FRAGS;
> +
> +	skb_walk_frags(skb, iter) {
> +		if (hlen + skb_headlen(iter) > len)
> +			return false;
> +	}
> +
> +	return true;
> +}
> +EXPORT_SYMBOL_GPL(skb_gso_validate_len);
> +
>  static struct sk_buff *skb_reorder_vlan_header(struct sk_buff *skb)
>  {
>  	if (skb_cow(skb, skb_headroom(skb)) < 0) {
> -- 
> 2.14.1
> 

  reply	other threads:[~2018-01-18 23:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16  2:09 [PATCH 0/3] Check gso_size of packets when forwarding Daniel Axtens
2018-01-16  2:09 ` [PATCH 1/3] net: move skb_gso_mac_seglen to skbuff.h Daniel Axtens
2018-01-16  2:09 ` [PATCH 2/3] net: is_skb_forwardable: validate length of GSO packet segments Daniel Axtens
2018-01-18 23:47   ` Marcelo Ricardo Leitner [this message]
2018-01-16  2:09 ` [PATCH 3/3] openvswitch: drop GSO packets that are too large Daniel Axtens
     [not found] ` <20180116020920.20232-1-dja-Yfaxwxk/+vWsTnJN9+BGXg@public.gmane.org>
2018-01-17 20:20   ` [PATCH 0/3] Check gso_size of packets when forwarding David Miller
2018-01-18  8:28 ` Pravin Shelar
2018-01-18  9:49   ` Jason Wang
2018-01-18 13:17     ` Daniel Axtens
     [not found]       ` <87fu735ms5.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-18 14:05         ` Daniel Axtens
     [not found]   ` <CAOrHB_AAMzYCLsFe6+3ODSqYUe79vYtP5jSxK=GDj5rKeQXyDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-18 13:08     ` Daniel Axtens
2018-01-18 21:57       ` Pravin Shelar
     [not found]         ` <CAOrHB_CyTg4iZ38T0WeNkC6ng3iznXKk+0Qr-rA2rs7ivSSf+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-19  1:28           ` Daniel Axtens
     [not found]             ` <87a7xa63ix.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-19  6:11               ` Daniel Axtens
2018-01-19  7:08             ` Pravin Shelar
2018-01-19 11:58               ` Daniel Axtens
     [not found]                 ` <871sim5abx.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-19 21:54                   ` Pravin Shelar
2018-01-22 20:14                     ` David Miller
2018-01-22 21:31                       ` Stephen Hemminger
2018-01-23  5:47                       ` Pravin Shelar

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=20180118234737.GA3502@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=Manish.Chopra@cavium.com \
    --cc=dev@openvswitch.org \
    --cc=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;
as well as URLs for NNTP newsgroup(s).