From patchwork Wed May 27 17:40:32 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Duyck X-Patchwork-Id: 477206 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 58D8B14010F for ; Thu, 28 May 2015 03:40:50 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751633AbbE0Rkq (ORCPT ); Wed, 27 May 2015 13:40:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53669 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbbE0Rkp (ORCPT ); Wed, 27 May 2015 13:40:45 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4RHeXFe021877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 27 May 2015 13:40:34 -0400 Received: from [192.168.122.149] (vpn-230-80.phx2.redhat.com [10.3.230.80]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4RHeWdp031454; Wed, 27 May 2015 13:40:32 -0400 Subject: [PATCH] xfrm6: Do not use xfrm_local_error for path MTU issues in tunnels From: Alexander Duyck To: steffen.klassert@secunet.com, davem@davemloft.net, herbert@gondor.apana.org.au Cc: netdev@vger.kernel.org, linux-crypto@vger.kernel.org Date: Wed, 27 May 2015 10:40:32 -0700 Message-ID: <20150527173823.1415.96248.stgit@ahduyck-vm-fedora22> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This change makes it so that we use icmpv6_send to report PMTU issues back into tunnels in the case that the resulting packet is larger than the MTU of the outgoing interface. Previously xfrm_local_error was being used in this case, however this was resulting in no changes, I suspect due to the fact that the tunnel itself was being kept out of the loop. This patch fixes PMTU problems seen on ip6_vti tunnels and is based on the behavior seen if the socket was orphaned. Instead of requiring the socket to be orphaned this patch simply defaults to using icmpv6_send in the case that the frame came though a tunnel. Signed-off-by: Alexander Duyck --- net/ipv6/xfrm6_output.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c index 09c76a7b474d..6f9b514d0e38 100644 --- a/net/ipv6/xfrm6_output.c +++ b/net/ipv6/xfrm6_output.c @@ -72,6 +72,7 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb) { int mtu, ret = 0; struct dst_entry *dst = skb_dst(skb); + struct xfrm_state *x = dst->xfrm; mtu = dst_mtu(dst); if (mtu < IPV6_MIN_MTU) @@ -82,7 +83,7 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb) if (xfrm6_local_dontfrag(skb)) xfrm6_local_rxpmtu(skb, mtu); - else if (skb->sk) + else if (skb->sk && x->props.mode != XFRM_MODE_TUNNEL) xfrm_local_error(skb, mtu); else icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu); @@ -149,11 +150,16 @@ static int __xfrm6_output(struct sock *sk, struct sk_buff *skb) else mtu = dst_mtu(skb_dst(skb)); - if (skb->len > mtu && xfrm6_local_dontfrag(skb)) { - xfrm6_local_rxpmtu(skb, mtu); - return -EMSGSIZE; - } else if (!skb->ignore_df && skb->len > mtu && skb->sk) { - xfrm_local_error(skb, mtu); + if (!skb->ignore_df && skb->len > mtu) { + skb->dev = dst->dev; + + if (xfrm6_local_dontfrag(skb)) + xfrm6_local_rxpmtu(skb, mtu); + else if (skb->sk && x->props.mode != XFRM_MODE_TUNNEL) + xfrm_local_error(skb, mtu); + else + icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu); + return -EMSGSIZE; }