From patchwork Tue Jun 5 22:04:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 10449387 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B4FF26024A for ; Tue, 5 Jun 2018 22:05:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 979DC29999 for ; Tue, 5 Jun 2018 22:05:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8C34F29D21; Tue, 5 Jun 2018 22:05:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C545129999 for ; Tue, 5 Jun 2018 22:05:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752405AbeFEWFO (ORCPT ); Tue, 5 Jun 2018 18:05:14 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:52711 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbeFEWFN (ORCPT ); Tue, 5 Jun 2018 18:05:13 -0400 Received: by mail-it0-f67.google.com with SMTP id m194-v6so5502063itg.2 for ; Tue, 05 Jun 2018 15:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=OCToFt3NzbOfiX4ZjlPhxR6Pje2RoxaH5SKl+Gf8E8U=; b=j+8tIYQUuMzowubtRy0nHUVgobLRS0W+M1P8RcHRiFia5n+1Qf5Km8eFSR0XQmZoTI 7AIBqKcCSucmLjtrG6vaagYjwl7vh+TljLX4zQ8opElEIa8jD3k0JJ4lMOIWeMKej8Aa 9/N6Vr1E89YdM9ipM2MjPQRCdwT1oBQ9RDnxkAfQf8YUiZ3nkzOzHRFw66+wuoKyOTjq 23Wz2vv/5mwBmuQDOzcekYUTIS9Lj9RKCz0pzckd6yUvqZ6ja+7HyEeWx3dfFuf07C3I yOhuYzO51QEVkRQGkXMOM/YCk2TA7M3Bz18gmKZkhUTEtQVwHGwkV4v9w+f4os8mZIGa tm8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=OCToFt3NzbOfiX4ZjlPhxR6Pje2RoxaH5SKl+Gf8E8U=; b=iC4AjOzNpqo5M/D163r3L+4yVJ34y50koMBe6snnhHGZv7gxDh59uUpzpHEv61vCrr Ya9WW18btGR6gkaD+tbuAa+jcn2Q1wDZAgYDfZSwvPlSNzh/PIrGWRlMy1nw4sJWJmle Eoj6/uQzSV7vPBqIIHBhssUth+s9UT+nT6rhUSIp4IUjMS/+hOB95DioGG+X1DKDlkIc YSZgPZqGGSUaPmtTO9U2xzNJ1LFZOvVgqggSn0NmlvxYKaqI72LqsYKF0ArFIPOUL5qk 1l5XR1BN7YCHKM0MDbZsLlv3Q+FWcLReN96qrtnbS1pk+wzPcCUo5F3vNTLJuaLS2AxK /pYA== X-Gm-Message-State: APt69E0XAdp7i9A6lN7wHg4HNZRpJ1XXuZkKFUSAs7tpI9hRSFedujAS QyoQitFbDHwQx0q3ZLGH0S7wNtdg X-Google-Smtp-Source: ADUXVKLDhK1IE89BgNyn7Br34Tj6pEwWCjFq4utICNAIKWqF0iQ5ACOoF1b5hhpiXAG7bRwfVI1BdQ== X-Received: by 2002:a24:a40b:: with SMTP id z11-v6mr28525ite.125.1528236313075; Tue, 05 Jun 2018 15:05:13 -0700 (PDT) Received: from x220t.lan ([64.26.149.125]) by smtp.gmail.com with ESMTPSA id a43-v6sm1180526itj.11.2018.06.05.15.05.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 15:05:12 -0700 (PDT) From: Alexander Aring To: netdev@vger.kernel.org Cc: davem@davemloft.net, yoshfuji@linux-ipv6.org, david.palma@ntnu.no, rabinarayans0828@gmail.com, jhs@mojatatu.com, stefan@osg.samsung.com, linux-wpan@vger.kernel.org, kernel@mojatatu.com, Alexander Aring Subject: [PATCH net] net: ipv6: ip6_output: alloc skb with tailroom Date: Tue, 5 Jun 2018 18:04:04 -0400 Message-Id: <20180605220404.6425-1-aring@mojatatu.com> X-Mailer: git-send-email 2.11.0 Sender: linux-wpan-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wpan@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch adds care about tailroom length for allocate a skb from ipv6 level stack. In case of 6lowpan we had the problem the skb runs into a skb_over_panic() in some special length cases. The root was there was no tailroom allocated for the IEEE 802.15.4 checksum, although we had the necessary tailroom specified inside the netdev structure. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059 Reported-by: David Palma Reported-by: Rabi Narayan Sahoo Signed-off-by: Alexander Aring --- Hi, nasty bug, I suppose this is the correct fix to my last question for what dev->needed_tailroom is designed for. I added two Reported-by here, David Palma reported this bug one year ago and I didn't had time to investigate. Interesting is that he told this bug doesn't occur (in case of 6lowpan 802.15.4) on 32 bit systems. Maybe alignment is related to the question why it works on 32 bit. Anyway, a week ago "Rabi Narayan Sahoo" reported the bug again and I needed to investigate something "why", since I also use a 64 bit vm. David Palma did a nice job for reproduce this bug and he (I think) lives at least one year with it, so I put him at first. Anyway, Rabi Narayan Sahoo was very very close to fix it and found the right code part which I also found. I read his mail afterwards because it was received messed on the linux-wpan mailinglist. So it's correct to give him credits too. :-) I hope there are no other cases where tailroom is missing. The second one is not needed to fix my bug but I think we need it there. Also hh_len is also used inside a skb_resever() in this function, but this is for headroom only. - Alex net/ipv6/ip6_output.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 7b6d1689087b..b4e521cfe3cf 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1262,6 +1262,7 @@ static int __ip6_append_data(struct sock *sk, int exthdrlen = 0; int dst_exthdrlen = 0; int hh_len; + int t_len; int copy; int err; int offset = 0; @@ -1283,6 +1284,7 @@ static int __ip6_append_data(struct sock *sk, orig_mtu = mtu; hh_len = LL_RESERVED_SPACE(rt->dst.dev); + t_len = rt->dst.dev->needed_tailroom; fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + (opt ? opt->opt_nflen : 0); @@ -1425,13 +1427,13 @@ static int __ip6_append_data(struct sock *sk, } if (transhdrlen) { skb = sock_alloc_send_skb(sk, - alloclen + hh_len, + alloclen + hh_len + t_len, (flags & MSG_DONTWAIT), &err); } else { skb = NULL; if (refcount_read(&sk->sk_wmem_alloc) + wmem_alloc_delta <= 2 * sk->sk_sndbuf) - skb = alloc_skb(alloclen + hh_len, + skb = alloc_skb(alloclen + hh_len + t_len, sk->sk_allocation); if (unlikely(!skb)) err = -ENOBUFS;