From patchwork Sat Nov 19 07:36:57 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Timo Teras X-Patchwork-Id: 126528 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 3E90EB7234 for ; Sat, 19 Nov 2011 18:37:14 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752166Ab1KSHhH (ORCPT ); Sat, 19 Nov 2011 02:37:07 -0500 Received: from mail-bw0-f46.google.com ([209.85.214.46]:50623 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751828Ab1KSHhF (ORCPT ); Sat, 19 Nov 2011 02:37:05 -0500 Received: by bke11 with SMTP id 11so4315324bke.19 for ; Fri, 18 Nov 2011 23:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=gc2MgacaWm7WfrFkgYzGK/3CoM2QJ3OFe0MraFx/y2Y=; b=iizbGRsOCbFMYU4AUckhlSLJKlbfL79BkKn6YiaUdOPRIa5x2tLxyaU7BEWMXqs1xQ jBMJe0Ry3ldML4F83MXIUU5Nnb+kLrtWS6oouJ2yE+kWlBV3s2kUa9cIvfuTvkPRtvgk 8y3DA3eSuAO4LeEF0Nvr3TO06crILJ5oZmq20= Received: by 10.205.133.4 with SMTP id hw4mr6393556bkc.91.1321688224277; Fri, 18 Nov 2011 23:37:04 -0800 (PST) Received: from [10.26.97.209] ([83.145.235.194]) by mx.google.com with ESMTPS id j16sm2451352bkv.14.2011.11.18.23.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 23:37:02 -0800 (PST) Message-ID: <4EC75C99.4000304@iki.fi> Date: Sat, 19 Nov 2011 09:36:57 +0200 From: =?ISO-8859-1?Q?Timo_Ter=E4s?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111116 Thunderbird/9.0 MIME-Version: 1.0 To: Nick Bowler CC: Eric Dumazet , netdev@vger.kernel.org, "David S. Miller" Subject: Re: Occasional oops with IPSec and IPv6. References: <20111117190925.GA23214@elliptictech.com> <20111118162709.GA8342@elliptictech.com> <1321634378.3277.35.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <4EC6A38E.6060404@iki.fi> <20111118192639.GA10531@elliptictech.com> <4EC6BAD7.3010200@iki.fi> <20111118212129.GA22495@elliptictech.com> In-Reply-To: <20111118212129.GA22495@elliptictech.com> X-Enigmail-Version: 1.3.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 11/18/2011 11:21 PM, Nick Bowler wrote: > On 2011-11-18 22:06 +0200, Timo Teräs wrote: >> It's still headroom underrun. >> >> I'm not too familiar with the relevant IPv6 code, but it seems to be >> mostly modelled after the IPv4 side. Looking at the back trace offset >> inside ipv6_fragment, I'd say it was taking the "fast path" for >> constructing the fragments. So first guess is that the headroom check >> for allowing fast path to happen is not right. >> >> Since the code seems to be treating separately hlen and struct frag_hdr, >> I'm wondering if the following patch would be in place? >> >> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c >> index 1c9bf8b..c35d9fc 100644 >> --- a/net/ipv6/ip6_output.c >> +++ b/net/ipv6/ip6_output.c >> @@ -675,7 +675,7 @@ int ip6_fragment(struct sk_buff *skb, int >> (*output)(struct sk_buff *)) >> /* Correct geometry. */ >> if (frag->len > mtu || >> ((frag->len & 7) && frag->next) || >> - skb_headroom(frag) < hlen) >> + skb_headroom(frag) < hlen + sizeof(struct frag_hdr)) >> goto slow_path_clean; >> >> /* Partially cloned skb? */ >> >> >> Alternatively, we could just run the "slow path" unconditionally with >> the test load to see if it fixes the issue. At least that'd be pretty >> good test if it's a problem in the ipv6 fragmentation code or something >> else. > > Good call. I replaced the "correct geometry" check with an > unconditional "goto slow_path_clean;", and I can no longer reproduce the > crash. So at the very least, I have a workaround now. (I still have > Herbert Xu's six patches applied on top of Linus' master). Ok, so it's most likely ipv6 code issue then. My change just happened to trigger it. > I then tried the smaller change above, but this does not correct the > issue. That's not it then (likely). I did notice that the headroom of the main skb is never checked. So my other suggestion is to try something like: skb_walk_frags(skb, frag) { Other than that, I hope some of the ipv6 people could take a look at it. But the problem is that somewhere some headroom check isn't taking place, or is checking for too little of headroom. - Timo --- 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/ip6_output.c b/net/ipv6/ip6_output.c index 1c9bf8b..735c4dc 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -668,7 +668,8 @@ int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *)) if (first_len - hlen > mtu || ((first_len - hlen) & 7) || - skb_cloned(skb)) + skb_cloned(skb) || + skb_headroom(skb) < sizeof(struct frag_hdr)) goto slow_path;