All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: xiyou.wangcong@gmail.com, linux@stwm.de, netdev@vger.kernel.org,
	eric.dumazet@gmail.com, therbert@google.com
Subject: Re: [PATCH net v3] ipv4: ipv6: better estimate tunnel header cut for correct ufo handling
Date: Wed, 26 Feb 2014 14:47:35 +0100	[thread overview]
Message-ID: <20140226134735.GD24855@order.stressinduktion.org> (raw)
In-Reply-To: <20140225.182746.1170300275583266483.davem@davemloft.net>

On Tue, Feb 25, 2014 at 06:27:46PM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Mon, 24 Feb 2014 00:48:05 +0100
> 
> > Currently the UFO fragmentation process does not correctly handle inner
> > UDP frames.
>  ...
> > In this case fragmentation id is incremented and offset is not updated.
> > 
> > First, I aligned inet_gso_segment and ipv6_gso_segment:
> > * align naming of flags
> > * ipv6_gso_segment: setting skb->encapsulation is unnecessary, as we
> >   always ensure that the state of this flag is left untouched when
> >   returning from upper gso segmenation function
> > * ipv6_gso_segment: move skb_reset_inner_headers below updating the
> >   fragmentation header data, we don't care for updating fragmentation
> >   header data
> > * remove currently unneeded comment indicating skb->encapsulation might
> >   get changed by upper gso_segment callback (gre and udp-tunnel reset
> >   encapsulation after segmentation on each fragment)
> > 
> > If we encounter an IPIP or SIT gso skb we now check for the protocol ==
> > IPPROTO_UDP and that we at least have already traversed another ip(6)
> > protocol header.
> > 
> > The reason why we have to special case GSO_IPIP and GSO_SIT is that
> > we reset skb->encapsulation to 0 while skb_mac_gso_segment the inner
> > protocol of GSO_UDP_TUNNEL or GSO_GRE packets.
> > 
> > Reported-by: Wolfgang Walter <linux@stwm.de>
> > Cc: Cong Wang <xiyou.wangcong@gmail.com>
> > Cc: Tom Herbert <therbert@google.com>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> 
> Applied, thanks Hannes.

This bug is present and was reported on v3.13 kernels, so I also would propose
this for v3.13. I hoped it would be clear from the thread, but should have
stated this more clearly.

It really is only appropriate there as this problem was introduced with
61c1db7fae21ed ("ipv6: sit: add GSO/TSO support") and cb32f511a70be8
("ipip: add GSO/TSO support"), both introduced in v3.13.

Thanks,

  Hannes

  reply	other threads:[~2014-02-26 13:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 17:47 linux 3.13: problems with isatap tunnel device and UFO Wolfgang Walter
2014-02-07 17:56 ` Hannes Frederic Sowa
2014-02-07 18:17   ` Wolfgang Walter
2014-02-07 22:22     ` Hannes Frederic Sowa
2014-02-08 23:17       ` Wolfgang Walter
2014-02-11  2:44         ` Hannes Frederic Sowa
2014-02-11 17:42           ` Wolfgang Walter
2014-02-17 16:09             ` Hannes Frederic Sowa
2014-02-20  2:44               ` Hannes Frederic Sowa
2014-02-20  2:54                 ` Hannes Frederic Sowa
2014-02-21  0:43                 ` Cong Wang
2014-02-21  1:19                   ` Hannes Frederic Sowa
2014-02-23 21:05                     ` [PATCH net] ipv4: ipv6: better estimate tunnel header cut for correct ufo handling Hannes Frederic Sowa
2014-02-23 21:24                       ` [PATCH net v2] " Hannes Frederic Sowa
2014-02-23 23:48                         ` [PATCH net v3] " Hannes Frederic Sowa
2014-02-25 23:27                           ` David Miller
2014-02-26 13:47                             ` Hannes Frederic Sowa [this message]
2014-02-26 18:45                               ` David Miller
2014-03-07 14:13                           ` Wolfgang Walter

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=20140226134735.GD24855@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=linux@stwm.de \
    --cc=netdev@vger.kernel.org \
    --cc=therbert@google.com \
    --cc=xiyou.wangcong@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.