From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Edward Cree <ecree@solarflare.com>
Cc: John Hurley <john.hurley@netronome.com>, <netdev@vger.kernel.org>,
<davem@davemloft.net>, <fw@strlen.de>, <jhs@mojatatu.com>,
<simon.horman@netronome.com>, <oss-drivers@netronome.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: Re: [RFC net-next 1/2] net: sched: refactor reinsert action
Date: Tue, 18 Jun 2019 11:57:12 -0700 [thread overview]
Message-ID: <20190618115712.7bb168c2@cakuba.netronome.com> (raw)
In-Reply-To: <dbd77b82-5951-8512-bc9d-e47abd400be3@solarflare.com>
On Mon, 17 Jun 2019 19:43:53 +0100, Edward Cree wrote:
> On 14/06/2019 15:33, John Hurley wrote:
> > Instead of
> > returning TC_ACT_REINSERT, change the type to the new TC_ACT_CONSUMED
> > which tells the caller that the packet has been stolen by another process
> > and that no consume call is required.
> Possibly a dumb question, but why does this need a new CONSUMED rather
> than, say, taking an additional ref and returning TC_ACT_STOLEN?
Is it okay to reinsert a shared skb into the stack? In particular this
looks a little scary:
int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
gfp_t gfp_mask)
{
int i, osize = skb_end_offset(skb);
int size = osize + nhead + ntail;
long off;
u8 *data;
BUG_ON(nhead < 0);
BUG_ON(skb_shared(skb));
^^^^^^^^^^^^^^^^^^^^^^^^
Actually looking for Paolo's address to add him to CC I found that he
said at the time:
With ACT_SHOT caller/upper layer will free the skb, too. We will have
an use after free (from either the upper layer and the xmit device).
Similar issues with STOLEN, TRAP, etc.
In the past, Changli Gao attempted to avoid the clone incrementing the
skb usage count:
commit 210d6de78c5d7c785fc532556cea340e517955e1
Author: Changli Gao <xiaosuo@gmail.com>
Date: Thu Jun 24 16:25:12 2010 +0000
act_mirred: don't clone skb when skb isn't shared
but some/many device drivers expect an skb usage count of 1, and that
caused ooops and was revered.
:)
next prev parent reply other threads:[~2019-06-18 18:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 14:33 [RFC net-next 0/2] Track recursive calls in TC act_mirred John Hurley
2019-06-14 14:33 ` [RFC net-next 1/2] net: sched: refactor reinsert action John Hurley
2019-06-17 18:43 ` Edward Cree
2019-06-17 22:11 ` John Hurley
2019-06-18 18:57 ` Jakub Kicinski [this message]
2019-06-14 14:33 ` [RFC net-next 2/2] net: sched: protect against stack overflow in TC act_mirred John Hurley
2019-06-14 14:45 ` Florian Westphal
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=20190618115712.7bb168c2@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=fw@strlen.de \
--cc=jhs@mojatatu.com \
--cc=john.hurley@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=pabeni@redhat.com \
--cc=simon.horman@netronome.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 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).