From: Sabrina Dubroca <sd@queasysnail.net>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Rahul Rameshbabu <rrameshbabu@nvidia.com>,
netdev@vger.kernel.org, Gal Pressman <gal@nvidia.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Radu Pirea <radu-nicolae.pirea@oss.nxp.com>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH net] Revert "net: macsec: use skb_ensure_writable_head_tail to expand the skb"
Date: Tue, 16 Jan 2024 14:51:19 +0100 [thread overview]
Message-ID: <ZaaJ17btw2PtW-Sd@hog> (raw)
In-Reply-To: <9b1d136c156b33759a0323e988b73839d5920acc.camel@redhat.com>
2024-01-16, 11:39:35 +0100, Paolo Abeni wrote:
> On Sun, 2024-01-14 at 09:42 -0800, Rahul Rameshbabu wrote:
> > This reverts commit b34ab3527b9622ca4910df24ff5beed5aa66c6b5.
> >
> > Using skb_ensure_writable_head_tail without a call to skb_unshare causes
> > the MACsec stack to operate on the original skb rather than a copy in the
> > macsec_encrypt path. This causes the buffer to be exceeded in space, and
> > leads to warnings generated by skb_put operations.
>
> This part of the changelog is confusing to me. It looks like the skb
> should be uncloned under the same conditions before and after this
> patch (and/or the reverted)??!
I don't think so. The old code was doing unshare +
expand. skb_ensure_writable_head_tail calls pskb_expand_head without
unshare, which doesn't give us a fresh sk_buff, only takes care of the
headroom/tailroom. Or do I need more coffee? :/
> Possibly dev->needed_headroom/needed_tailroom values are incorrect?!?
That's also possible following commit a73d8779d61a ("net: macsec:
introduce mdo_insert_tx_tag"). Then this revert would only be hiding
the issue.
--
Sabrina
next prev parent reply other threads:[~2024-01-16 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-14 17:42 [PATCH net] Revert "net: macsec: use skb_ensure_writable_head_tail to expand the skb" Rahul Rameshbabu
2024-01-16 10:39 ` Paolo Abeni
2024-01-16 13:51 ` Sabrina Dubroca [this message]
2024-01-16 20:45 ` Rahul Rameshbabu
2024-01-17 1:22 ` Rahul Rameshbabu
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=ZaaJ17btw2PtW-Sd@hog \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=radu-nicolae.pirea@oss.nxp.com \
--cc=rrameshbabu@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.