From: Paolo Abeni <pabeni@redhat.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Eyal Birger <eyal.birger@gmail.com>
Subject: Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible
Date: Fri, 20 Jul 2018 12:16:36 +0200 [thread overview]
Message-ID: <bc9880ab85609b5b44eae59feba83011fbf04f92.camel@redhat.com> (raw)
In-Reply-To: <CAM_iQpUdW765kzsbZfXpPLdtoxEtNWj38d7Ev=v0a-pJGMd-qQ@mail.gmail.com>
On Thu, 2018-07-19 at 10:56 -0700, Cong Wang wrote:
> On Wed, Jul 18, 2018 at 3:05 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > Hi,
> >
> > On Tue, 2018-07-17 at 10:24 -0700, Cong Wang wrote:
> > > If you goal is to get rid of skb_clone(), why not just do the following?
> > >
> > > if (tcf_mirred_is_act_redirect(m_eaction)) {
> > > skb2 = skb;
> > > } else {
> > > skb2 = skb_clone(skb, GFP_ATOMIC);
> > > if (!skb2)
> > > goto out;
> > > }
> > >
> > > For redirect, we return TC_ACT_SHOT, so upper layer should not
> > > touch the skb after that.
> > >
> > > What am I missing here?
> >
> > 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.
>
> Interesting, I wasn't aware of the above commit and its revert.
>
> First, I didn't use skb_get() above.
>
> Second, I think the caller of dev_queue_xmit() should not
> touch the skb after it, the skb is either freed by dev_queue_xmit()
> or successfully transmitted, in either case, the ownership belongs
> to dev_queue_xmit(). So, I think we should skip the qdisc_drop()
> for this case.
>
> Not sure about netif_receive_skb() case, given veth calls in its
> xmit too, I speculate the rule is probably same.
>
> Not sure about other ACT_SHOT case than act_mirred...
I think any tc filter can be configured from user space to return
ACT_SHOT, so changing the ACT_SHOT handling would be quite invasive and
error prone, as all the tc filters (to free the skb on ACT_SHOT) and tc
schedulers (to avoid touching the skb) must be modified.
If there are no strong objection vs a new action value, I would opt for
such option.
Thanks,
Paolo
next prev parent reply other threads:[~2018-07-20 11:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 9:54 [PATCH net-next 0/4] TC: refactor TC_ACT_REDIRECT action Paolo Abeni
2018-07-13 9:54 ` [PATCH net-next 1/4] tc/act: user space can't use TC_ACT_REDIRECT directly Paolo Abeni
2018-07-13 9:55 ` [PATCH net-next 2/4] tc/act: remove unneeded RCU lock in action callback Paolo Abeni
2018-07-13 14:08 ` Daniel Borkmann
2018-07-13 14:26 ` Paolo Abeni
2018-07-13 14:41 ` Daniel Borkmann
2018-07-13 15:00 ` Paolo Abeni
2018-07-13 9:55 ` [PATCH net-next 3/4] net/sched: refactor TC_ACT_REDIRECT handling Paolo Abeni
2018-07-13 14:13 ` Daniel Borkmann
2018-07-13 14:37 ` Paolo Abeni
2018-07-13 16:32 ` Daniel Borkmann
2018-07-13 9:55 ` [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible Paolo Abeni
2018-07-16 23:39 ` Cong Wang
2018-07-17 7:01 ` Eyal Birger
2018-07-17 9:15 ` Paolo Abeni
2018-07-17 9:38 ` Dave Taht
2018-07-17 17:24 ` Cong Wang
2018-07-18 10:05 ` Paolo Abeni
2018-07-19 17:56 ` Cong Wang
2018-07-20 10:16 ` Paolo Abeni [this message]
2018-07-19 17:16 ` kbuild test robot
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=bc9880ab85609b5b44eae59feba83011fbf04f92.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eyal.birger@gmail.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.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).