netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IPv6 xfrm GSO fragmentation bug
@ 2015-08-30  8:24 Herbert Xu
  2015-08-31  7:19 ` Steffen Klassert
  0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2015-08-30  8:24 UTC (permalink / raw)
  To: Steffen Klassert, netdev

Hi Steffen:

I received a bug report regarding poor IPComp performance over
IPv6:

	https://bugzilla.redhat.com/show_bug.cgi?id=1257952

It appears to have been caused by

commit dd767856a36e00b631d65ebc4bb81b19915532d6
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Oct 11 01:44:30 2011 +0000

    xfrm6: Don't call icmpv6_send on local error

which addded an MTU check without a GSO override.

Fixing it obviously isn't difficult, but I am wondering why I
can't find a corresponding patch for IPv4.  Do we need that check
to be present in xfrm6_output at all? If we do why isn't it needed
for IPv4 as well?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

* Re: IPv6 xfrm GSO fragmentation bug
  2015-08-30  8:24 IPv6 xfrm GSO fragmentation bug Herbert Xu
@ 2015-08-31  7:19 ` Steffen Klassert
  2015-08-31  7:35   ` Herbert Xu
  0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2015-08-31  7:19 UTC (permalink / raw)
  To: Herbert Xu; +Cc: netdev

On Sun, Aug 30, 2015 at 04:24:32PM +0800, Herbert Xu wrote:
> Hi Steffen:
> 
> I received a bug report regarding poor IPComp performance over
> IPv6:
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=1257952
> 
> It appears to have been caused by
> 
> commit dd767856a36e00b631d65ebc4bb81b19915532d6
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date:   Tue Oct 11 01:44:30 2011 +0000
> 
>     xfrm6: Don't call icmpv6_send on local error
> 
> which addded an MTU check without a GSO override.
> 
> Fixing it obviously isn't difficult, but I am wondering why I
> can't find a corresponding patch for IPv4.  Do we need that check
> to be present in xfrm6_output at all? If we do why isn't it needed
> for IPv4 as well?

As far as I remember, this was to catch local message size
errors before __xfrm6_output calls ip6_fragment which would
use icmpv6_send for the error notification. IPv4 does not do
fragmentation in the xfrm4_output functions, so this mtu
check was not needed there.

I think just adding the gso checks should be fine.

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

* Re: IPv6 xfrm GSO fragmentation bug
  2015-08-31  7:19 ` Steffen Klassert
@ 2015-08-31  7:35   ` Herbert Xu
  2015-09-04  5:21     ` Herbert Xu
  0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2015-08-31  7:35 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: netdev

On Mon, Aug 31, 2015 at 09:19:16AM +0200, Steffen Klassert wrote:
>
> As far as I remember, this was to catch local message size
> errors before __xfrm6_output calls ip6_fragment which would
> use icmpv6_send for the error notification. IPv4 does not do
> fragmentation in the xfrm4_output functions, so this mtu
> check was not needed there.
> 
> I think just adding the gso checks should be fine.

I see where the bug came from.  Indeed IPv6 does do fragmentation
but only for tunnel mode.  While your patch added a check that also
affected transport mode.  So in addition to the GSO fix we should
also make the MTU check conditional to tunnel mode.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

* Re: IPv6 xfrm GSO fragmentation bug
  2015-08-31  7:35   ` Herbert Xu
@ 2015-09-04  5:21     ` Herbert Xu
  2015-09-07 10:00       ` Steffen Klassert
  0 siblings, 1 reply; 5+ messages in thread
From: Herbert Xu @ 2015-09-04  5:21 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: netdev

On Mon, Aug 31, 2015 at 03:35:26PM +0800, Herbert Xu wrote:
> 
> I see where the bug came from.  Indeed IPv6 does do fragmentation
> but only for tunnel mode.  While your patch added a check that also
> affected transport mode.  So in addition to the GSO fix we should
> also make the MTU check conditional to tunnel mode.

Here is the patch:

---8<---
ipv6: Fix IPsec pre-encap fragmentation check

The IPv6 IPsec pre-encap path performs fragmentation for tunnel-mode
packets.  That is, we perform fragmentation pre-encap rather than
post-encap.

A check was added later to ensure that proper MTU information is
passed back for locally generated traffic.  Unfortunately this
check was performed on all IPsec packets, including transport-mode
packets.

What's more, the check failed to take GSO into account.

The end result is that transport-mode GSO packets get dropped at
the check.

This patch fixes it by moving the tunnel mode check forward as well
as adding the GSO check.

Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 09c76a7..be033f2 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -136,6 +136,7 @@ static int __xfrm6_output(struct sock *sk, struct sk_buff *skb)
 	struct dst_entry *dst = skb_dst(skb);
 	struct xfrm_state *x = dst->xfrm;
 	int mtu;
+	bool toobig;
 
 #ifdef CONFIG_NETFILTER
 	if (!x) {
@@ -144,25 +145,29 @@ static int __xfrm6_output(struct sock *sk, struct sk_buff *skb)
 	}
 #endif
 
+	if (x->props.mode != XFRM_MODE_TUNNEL)
+		goto skip_frag;
+
 	if (skb->protocol == htons(ETH_P_IPV6))
 		mtu = ip6_skb_dst_mtu(skb);
 	else
 		mtu = dst_mtu(skb_dst(skb));
 
-	if (skb->len > mtu && xfrm6_local_dontfrag(skb)) {
+	toobig = skb->len > mtu && !skb_is_gso(skb);
+
+	if (toobig && xfrm6_local_dontfrag(skb)) {
 		xfrm6_local_rxpmtu(skb, mtu);
 		return -EMSGSIZE;
-	} else if (!skb->ignore_df && skb->len > mtu && skb->sk) {
+	} else if (!skb->ignore_df && toobig && skb->sk) {
 		xfrm_local_error(skb, mtu);
 		return -EMSGSIZE;
 	}
 
-	if (x->props.mode == XFRM_MODE_TUNNEL &&
-	    ((skb->len > mtu && !skb_is_gso(skb)) ||
-		dst_allfrag(skb_dst(skb)))) {
+	if (toobig || dst_allfrag(skb_dst(skb)))
 		return ip6_fragment(sk, skb,
 				    x->outer_mode->afinfo->output_finish);
-	}
+
+skip_frag:
 	return x->outer_mode->afinfo->output_finish(sk, skb);
 }
 
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

* Re: IPv6 xfrm GSO fragmentation bug
  2015-09-04  5:21     ` Herbert Xu
@ 2015-09-07 10:00       ` Steffen Klassert
  0 siblings, 0 replies; 5+ messages in thread
From: Steffen Klassert @ 2015-09-07 10:00 UTC (permalink / raw)
  To: Herbert Xu; +Cc: netdev

On Fri, Sep 04, 2015 at 01:21:06PM +0800, Herbert Xu wrote:
> On Mon, Aug 31, 2015 at 03:35:26PM +0800, Herbert Xu wrote:
> > 
> > I see where the bug came from.  Indeed IPv6 does do fragmentation
> > but only for tunnel mode.  While your patch added a check that also
> > affected transport mode.  So in addition to the GSO fix we should
> > also make the MTU check conditional to tunnel mode.
> 
> Here is the patch:
> 
> ---8<---
> ipv6: Fix IPsec pre-encap fragmentation check
> 
> The IPv6 IPsec pre-encap path performs fragmentation for tunnel-mode
> packets.  That is, we perform fragmentation pre-encap rather than
> post-encap.
> 
> A check was added later to ensure that proper MTU information is
> passed back for locally generated traffic.  Unfortunately this
> check was performed on all IPsec packets, including transport-mode
> packets.
> 
> What's more, the check failed to take GSO into account.
> 
> The end result is that transport-mode GSO packets get dropped at
> the check.
> 
> This patch fixes it by moving the tunnel mode check forward as well
> as adding the GSO check.
> 
> Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied to the ipsec tree, thanks Herbert!

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

end of thread, other threads:[~2015-09-07 10:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-30  8:24 IPv6 xfrm GSO fragmentation bug Herbert Xu
2015-08-31  7:19 ` Steffen Klassert
2015-08-31  7:35   ` Herbert Xu
2015-09-04  5:21     ` Herbert Xu
2015-09-07 10:00       ` Steffen Klassert

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).