From patchwork Thu Aug 22 13:53:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hannes Frederic Sowa X-Patchwork-Id: 269078 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 545B62C00AC for ; Thu, 22 Aug 2013 23:53:48 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595Ab3HVNxo (ORCPT ); Thu, 22 Aug 2013 09:53:44 -0400 Received: from order.stressinduktion.org ([87.106.68.36]:39799 "EHLO order.stressinduktion.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752251Ab3HVNxo (ORCPT ); Thu, 22 Aug 2013 09:53:44 -0400 Received: by order.stressinduktion.org (Postfix, from userid 500) id 17ECD1A0C288; Thu, 22 Aug 2013 15:53:42 +0200 (CEST) Date: Thu, 22 Aug 2013 15:53:42 +0200 From: Hannes Frederic Sowa To: Steffen Klassert Cc: David Miller , netdev@vger.kernel.org Subject: Re: Problematic commits in the ipsec tree Message-ID: <20130822135342.GC30722@order.stressinduktion.org> Mail-Followup-To: Steffen Klassert , David Miller , netdev@vger.kernel.org References: <20130822104724.GD26773@secunet.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130822104724.GD26773@secunet.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Aug 22, 2013 at 12:47:24PM +0200, Steffen Klassert wrote: > Hannes, > > I have two problematic commits from you in the ipsec tree. The first one is: > > commit 0ea9d5e3e (xfrm: introduce helper for safe determination of mtu) > > This breakes pmtu discovery for IPv4 because now we use the device mtu > instead of the reduced IPsec mtu in xfrm4_tunnel_check_size() if a IPv4 > socket is at the skb. I am currently testing this following patch. It should restore old behavior for ipv4 sockets. Actually I would like to extend this check so that we only take the dst_mtu(dst->path) in case of IP_PMTUDISC_PROBE. But that would be a patch for ipsec-next. I was not sure if we always dispatch to xfrm_mtu in this code-path. > > The second is: > > commit 844d48746 (xfrm: choose protocol family by skb protocol) > > This breaks pmtu discovery for IPv6 too because skb->protocol can be null > in __xfrm6_output(). I am currently checking if there are side-effects if we set skb->protocol in raw sockets. This should solve this problem. Btw. this is also the case for IPv4. Hope to have tested patches later today. Thanks, Hannes --- 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/include/net/xfrm.h b/include/net/xfrm.h index ac5b025..65d3529 100644 --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -1730,8 +1730,6 @@ static inline int xfrm_skb_dst_mtu(struct sk_buff *skb) if (sk && skb->protocol == htons(ETH_P_IPV6)) return ip6_skb_dst_mtu(skb); - else if (sk && skb->protocol == htons(ETH_P_IP)) - return ip_skb_dst_mtu(skb); return dst_mtu(skb_dst(skb)); }