From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Andreas Steinmetz <ast@domdv.de>,
Network Development <netdev@vger.kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>
Subject: Re: [PATCH net-next 1/3] macsec: remove superfluous function calls
Date: Tue, 2 Jul 2019 21:50:33 -0400 [thread overview]
Message-ID: <CA+FuTScf_wNwLdph=GY6f==tu_cM-BeVbAUgnMVuyubGB2-T=g@mail.gmail.com> (raw)
In-Reply-To: <CA+FuTSfih0pBbOnXxkw4UpmiqDnNLf4k8O-=7XW4m7fj5ogqXw@mail.gmail.com>
On Sun, Jun 30, 2019 at 9:57 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz <ast@domdv.de> wrote:
> >
> > Remove superfluous skb_share_check() and skb_unshare().
> > macsec_decrypt is only called by macsec_handle_frame which
> > already does a skb_unshare().
>
> There is a subtle difference. skb_unshare() acts on cloned skbs, not
> shared skbs.
>
> It creates a private copy of data if clones may access it
> concurrently, which clearly is needed when modifying for decryption.
>
> At rx_handler, I don't think a shared skb happen (unlike clones, e.g.,
> from packet sockets). But it is peculiar that most, if not all,
> rx_handlers seem to test for it. That have started with the bridge
> device:
>
> commit 7b995651e373d6424f81db23f2ec503306dfd7f0
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sun Oct 14 00:39:01 2007 -0700
>
> [BRIDGE]: Unshare skb upon entry
>
> Due to the special location of the bridging hook, it should never see a
> shared packet anyway (certainly not with any in-kernel code). So it
> makes sense to unshare the skb there if necessary as that will greatly
> simplify the code below it (in particular, netfilter).
>
> Anyway, remove the check only if certain.
Did you see this point? I notice the v2 without this mentioned. I
don't think you can remove an skb_share_check solely on the basis of a
previous skb_unshare. I agree that here a shared skb is unlikely, but
that is for a very different, less obvious, reason.
>
> >
> > Signed-off-by: Andreas Steinmetz <ast@domdv.de>
> >
> > --- a/drivers/net/macsec.c 2019-06-30 22:02:54.906908179 +0200
> > +++ b/drivers/net/macsec.c 2019-06-30 22:03:07.315785186 +0200
> > @@ -939,9 +939,6 @@
> > u16 icv_len = secy->icv_len;
> >
> > macsec_skb_cb(skb)->valid = false;
> > - skb = skb_share_check(skb, GFP_ATOMIC);
> > - if (!skb)
> > - return ERR_PTR(-ENOMEM);
> >
> > ret = skb_cow_data(skb, 0, &trailer);
> > if (unlikely(ret < 0)) {
> > @@ -973,11 +970,6 @@
> >
> > aead_request_set_crypt(req, sg, sg, len, iv);
> > aead_request_set_ad(req, macsec_hdr_len(macsec_skb_cb(skb)->has_sci));
> > - skb = skb_unshare(skb, GFP_ATOMIC);
> > - if (!skb) {
> > - aead_request_free(req);
> > - return ERR_PTR(-ENOMEM);
> > - }
> > } else {
> > /* integrity only: all headers + data authenticated */
> > aead_request_set_crypt(req, sg, sg, icv_len, iv);
> >
prev parent reply other threads:[~2019-07-03 1:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-30 20:46 [PATCH net-next 1/3] macsec: remove superfluous function calls Andreas Steinmetz
2019-07-01 1:57 ` Willem de Bruijn
2019-07-03 1:50 ` Willem de Bruijn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+FuTScf_wNwLdph=GY6f==tu_cM-BeVbAUgnMVuyubGB2-T=g@mail.gmail.com' \
--to=willemdebruijn.kernel@gmail.com \
--cc=ast@domdv.de \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).