From: John Fastabend <john.fastabend@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: xiyou.wangcong@gmail.com, davem@davemloft.net, jhs@mojatatu.com,
netdev@vger.kernel.org, paulmck@linux.vnet.ibm.com,
brouer@redhat.com
Subject: Re: [net-next PATCH v5 13/16] net: sched: make tc_action safe to walk under RCU
Date: Fri, 12 Sep 2014 17:05:00 -0700 [thread overview]
Message-ID: <54138A2C.8000301@gmail.com> (raw)
In-Reply-To: <1410555114.7106.101.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/12/2014 01:51 PM, Eric Dumazet wrote:
> On Fri, 2014-09-12 at 09:34 -0700, John Fastabend wrote:
>
>> Second there is a suspect usage of list_splice_init_rcu() in the
>> tcf_exts_change() routine. Notice how it is used twice in succession
>> and the second init works on the src tcf_exts. There is probably a
>> better way to accomplish that.
Not only is it suspect its broke as best as I can tell.
>>
>
>
>> +/* It is not safe to use src->actions after this due to _init_rcu usage
>> + * INIT_LIST_HEAD_RCU() is called on src->actions
>> + */
>> void tcf_exts_change(struct tcf_proto *tp, struct tcf_exts *dst,
>> struct tcf_exts *src)
>> {
>> #ifdef CONFIG_NET_CLS_ACT
>> LIST_HEAD(tmp);
>> - tcf_tree_lock(tp);
>> - list_splice_init(&dst->actions, &tmp);
>> - list_splice(&src->actions, &dst->actions);
>> - tcf_tree_unlock(tp);
Here we have three lists,
tmp (which has just been initialized)
dst -> act1 -> act2 -> ... -> actn ->
src -> acta -> actb -> ... -> actn ->
The active list is dst from the tc_classify and we want to
switch to the src list
>> + list_splice_init_rcu(&dst->actions, &tmp, synchronize_rcu);
Now we spliced in tmp and did an INIT_LIST_HEAD_RCU() on dst->actions
(oops) so the lists look like this
tmp -> act1 -> act2 -> ... -> actn ->
dst
src -> acta -> actb -> ... -> actn ->
The active list is still dst from the tc_classify caller so now we are
missing both the old and new action lists. This is broke.
>> + list_splice_init_rcu(&src->actions,
>> + &dst->actions,
>> + synchronize_rcu);
But the final state is what we wanted,
tmp -> act1 -> act2 -> ... -> actn ->
dst -> acta -> actb -> ... -> actn ->
src
>> tcf_action_destroy(&tmp, TCA_ACT_UNBIND);
Finally clean it all up,
tmp
dst -> acta -> actb -> ... -> actn ->
src
>> #endif
>> }
>
> I am afraid I do not understand this part.
Because it doesn't work as far as I can tell. What I really want here
is to swap the head pointer with,
struct list_head *tmp = dst->actions;
rcu_assign_pointer(dst->actions, src->actions)
synchronize_rcu()
tcf_action_destroy(tmp);
This requires a bit more work. I'll work out a patch after a bit more
thought.
Thanks again!
.John
--
John Fastabend Intel Corporation
next prev parent reply other threads:[~2014-09-13 0:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 16:28 [net-next PATCH v5 00/16] net/sched rcu filters John Fastabend
2014-09-12 16:28 ` [net-next PATCH v5 01/16] net: qdisc: use rcu prefix and silence sparse warnings John Fastabend
2014-09-12 16:36 ` Eric Dumazet
2014-09-12 16:29 ` [net-next PATCH v5 02/16] net: rcu-ify tcf_proto John Fastabend
2014-09-12 16:40 ` Eric Dumazet
2014-09-12 16:29 ` [net-next PATCH v5 03/16] net: sched: cls_basic use RCU John Fastabend
2014-09-12 16:30 ` [net-next PATCH v5 04/16] net: sched: cls_cgroup " John Fastabend
2014-09-12 16:30 ` [net-next PATCH v5 05/16] net: sched: cls_flow " John Fastabend
2014-09-12 16:31 ` [net-next PATCH v5 06/16] net: sched: fw " John Fastabend
2014-09-12 16:31 ` [net-next PATCH v5 07/16] net: sched: RCU cls_route John Fastabend
2014-09-12 16:31 ` [net-next PATCH v5 08/16] net: sched: RCU cls_tcindex John Fastabend
2014-09-12 16:32 ` [net-next PATCH v5 09/16] net: sched: make cls_u32 per cpu John Fastabend
2014-09-12 16:32 ` [net-next PATCH v5 10/16] net: sched: make cls_u32 lockless John Fastabend
2014-09-12 16:33 ` [net-next PATCH v5 11/16] net: sched: rcu'ify cls_rsvp John Fastabend
2014-09-12 18:21 ` Eric Dumazet
2014-09-12 16:33 ` [net-next PATCH v5 12/16] net: sched: rcu'ify cls_bpf John Fastabend
2014-09-12 18:22 ` Eric Dumazet
2014-09-12 16:34 ` [net-next PATCH v5 13/16] net: sched: make tc_action safe to walk under RCU John Fastabend
2014-09-12 20:51 ` Eric Dumazet
2014-09-13 0:05 ` John Fastabend [this message]
2014-09-12 16:34 ` [net-next PATCH v5 14/16] net: sched: make bstats per cpu and estimator RCU safe John Fastabend
2014-09-12 23:49 ` Eric Dumazet
2014-09-12 16:34 ` [net-next PATCH v5 15/16] net: sched: make qstats per cpu John Fastabend
2014-09-12 23:55 ` Eric Dumazet
2014-09-12 16:35 ` [net-next PATCH v5 16/16] net: sched: drop ingress qdisc lock John Fastabend
2014-09-12 23:56 ` Eric Dumazet
2014-09-13 1:33 ` Eric Dumazet
2014-09-13 2:36 ` [net-next PATCH v5 00/16] net/sched rcu filters David Miller
2014-09-13 2:49 ` Eric Dumazet
2014-09-13 3:12 ` John Fastabend
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=54138A2C.8000301@gmail.com \
--to=john.fastabend@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--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 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.