From patchwork Thu Jun 7 16:22:33 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 10453167 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 6E87E60467 for ; Thu, 7 Jun 2018 16:22:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6D72F29C41 for ; Thu, 7 Jun 2018 16:22:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6AA5429C84; Thu, 7 Jun 2018 16:22:51 +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 2DB0D29C41 for ; Thu, 7 Jun 2018 16:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753549AbeFGQWl (ORCPT ); Thu, 7 Jun 2018 12:22:41 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:42357 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753444AbeFGQWk (ORCPT ); Thu, 7 Jun 2018 12:22:40 -0400 Received: by mail-io0-f196.google.com with SMTP id r24-v6so12479717ioh.9 for ; Thu, 07 Jun 2018 09:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AEtqwut2hodUB0/3JJxpWn4ARJvH4pqWpnDTlIlxJTs=; b=SPmZaJJKRX8Y7b91uMrT0HMydS/pKkMqoyaz/9ZYEGn/Org2jMlxLQNLIk7fBE/ls3 3ozg2JGuBGN0yq74aA54QzmeeP7xOZV9bQYdQnYeN7YRO1QCEHf79z4Hz8S4G6DzkAFF 9CausQ55inTUdEqzSohOxSGUqLy1aNXM8i7vqp5NPWelp09Y6j02FPA/1IJEdC7guKKf qpJugsmfzyMCzWoo87o/voB+lQY3/XkGiHishoWlaA+fHqnjGNjjPuAsexUV3uKL9UgS bSb9TOBpkDx2MtpaYv3dTAHK4jcw5+OlrCRKMAH4JvAshe79J1ovhMpQHjgTdqCm4t8B 0otA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AEtqwut2hodUB0/3JJxpWn4ARJvH4pqWpnDTlIlxJTs=; b=WR3P0XXTzPY4G+yGtCcArTFzHtb5QnhSaiK1rzJGAmCjSzuCPLsN9tfW38wTdp23la +TyHwTIPeSNSYpVBKAd6MYjMddCh9vTqdAJWFF3sGqueN/8iCXIJCNVo83N9XBYteFak bOwWtUGemXuEY5mTFSC6CVOKkpZuNYU2W4xT5xg6YoDMNanWo/5mdUEBdD8FI9Tk6d7K YpTZSIA750VmJ2Yx8KExeSvF3khD7tZc+R7oI2apoOZ+8cZ5qkXhjMNonvpRKddcJCAY Jy6KMvydWBQI7B5yeg4FKCU8skocwuoBOBvsychNm8BBX6wVixKmcHqf/TC5/p8Spius RAsg== X-Gm-Message-State: APt69E1dNSl1nzcby4XDUfwY0xc+jFnvr00/Ty0ZJxiaF/fstA8gu6lQ 5YixlUi8BmIjm0kG0LOIedZwfA== X-Google-Smtp-Source: ADUXVKJUpsrAMdqUMzNZjw/TBsIOZ06asFOaMDPfGXpS+0eOduWu9tUX3NnOPDcvyvuBsIEE81DSTw== X-Received: by 2002:a6b:5112:: with SMTP id f18-v6mr2218510iob.245.1528388560047; Thu, 07 Jun 2018 09:22:40 -0700 (PDT) Received: from x220t ([64.26.149.125]) by smtp.gmail.com with ESMTPSA id q203-v6sm443088itb.32.2018.06.07.09.22.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Jun 2018 09:22:39 -0700 (PDT) Date: Thu, 7 Jun 2018 12:22:33 -0400 From: Alexander Aring To: Willem de Bruijn Cc: David Miller , Network Development , Hideaki YOSHIFUJI , david.palma@ntnu.no, rabinarayans0828@gmail.com, Jamal Hadi Salim , stefan@osg.samsung.com, linux-wpan@vger.kernel.org, kernel@mojatatu.com, sd@queasysnail.net Subject: Re: [PATCH net] net: ipv6: ip6_output: alloc skb with tailroom Message-ID: <20180607162233.hepodtvuo7ictel2@x220t> References: <20180605220404.6425-1-aring@mojatatu.com> <20180606.135339.2253125602143741999.davem@davemloft.net> <20180606180853.zimcpxbo3ejxum6g@x220t> <20180606.141125.1145874895676180399.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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 Hi, On Wed, Jun 06, 2018 at 04:26:19PM -0400, Willem de Bruijn wrote: > On Wed, Jun 6, 2018 at 2:11 PM, David Miller wrote: > > From: Alexander Aring > > Date: Wed, 6 Jun 2018 14:09:20 -0400 > > > >> okay, then you want to have this patch for net-next? As an optimization? > >> > >> Of course, when it's open again. > > > > Like you, I have questions about where this adjustment is applied and > > why. So I'm not sure yet. > > > > For example, only IPV6 really takes it into consideration and as you > > saw only really for the fragmentation path and not the normal output > > path. > > > > This needs more consideration and investigation. > > This is the unconditional skb_put in ieee802154_tx. In many cases > there is some tailroom due to SKB_DATA_ALIGN in __alloc_skb, > so it may take a specific case to not have even 2 bytes of tailroom > available. Yes it's in ieee802154_tx, but we need tailroom not just for checksum. The bugreport is related to the two bytes of tailroom, because virtual hardware doing checksum by software. The most real transceivers offload this feature, so zero tailroom is needed. I will of course add checks before adding L2 header for headroom and tailroom in related subsystem code. In IEEE 802.15.4 and secured enabled frames we need a MIC field at the end of the frame. In worst case this can be 16 bytes. I looked ethernet macsec feature and it seems they need to have a similar reseved tailroom which is 16 bytes by default (max 32 bytes). Maybe it's worth to take care for the tailroom in this path since it's not just 2 bytes in some cases. --- Meanwhile I think I found a bug in macsec, I cc Sabrina here: --- MACSEC_NEEDED_TAILROOM is the define to check and run skb_copy_expand() and should use the ?worst case? or the the value (icv_len + ?extra_foo?) is set as runtime generation on newlink. I see that in macsec_newlink() following code: if (data && data[IFLA_MACSEC_ICV_LEN]) icv_len = nla_get_u8(data[IFLA_MACSEC_ICV_LEN]); so the user can change it to (even a value above 32?, there is no check for that). Anyway everything higher than MACSEC_STD_ICV_LEN could run into a skb_over_panic(). - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" 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/drivers/net/macsec.c b/drivers/net/macsec.c index 7de88b33d5b9..687323c0caf5 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -522,7 +522,7 @@ static bool macsec_validate_skb(struct sk_buff *skb, u16 icv_len) } #define MACSEC_NEEDED_HEADROOM (macsec_extra_len(true)) -#define MACSEC_NEEDED_TAILROOM MACSEC_STD_ICV_LEN +#define MACSEC_NEEDED_TAILROOM MACSEC_MAX_ICV_LEN static void macsec_fill_iv(unsigned char *iv, sci_t sci, u32 pn) {