From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Veaceslav Falico <vfalico@redhat.com>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>,
Ding Tianhong <dingtianhong@huawei.com>,
Jay Vosburgh <fubar@us.ibm.com>,
Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v4 1/6] bonding: simplify and use RCU protection for 3ad xmit path
Date: Thu, 12 Sep 2013 09:17:33 -0700 [thread overview]
Message-ID: <20130912161733.GQ3966@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130907150350.GF26163@redhat.com>
On Sat, Sep 07, 2013 at 05:03:50PM +0200, Veaceslav Falico wrote:
> On Sat, Sep 07, 2013 at 04:45:05PM +0200, Nikolay Aleksandrov wrote:
> >
> >On 09/07/2013 04:20 PM, Veaceslav Falico wrote:
> >>On Fri, Sep 06, 2013 at 03:28:07PM +0800, Ding Tianhong wrote:
> ...snip...
> >>diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> >>index f4b1001..37b49d1 100644
> >>--- a/include/linux/rculist.h
> >>+++ b/include/linux/rculist.h
> >>@@ -23,6 +23,7 @@
> >> * way, we must not access it directly
> >> */
> >> #define list_next_rcu(list) (*((struct list_head __rcu
> >>**)(&(list)->next)))
> >>+#define list_prev_rcu(list) (*((struct list_head __rcu
> >>**)(&(list)->prev)))
> >>
> >> /*
> >> * Insert a new entry between two known consecutive entries.
> >>@@ -271,6 +272,12 @@ static inline void list_splice_init_rcu(struct
> >>list_head *list,
> >> likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
> >> })
> >>
> >>+#define list_last_or_null_rcu(ptr, type, member) \
> >>+ ({struct list_head *__ptr = (ptr); \
> >>+ struct list_head __rcu *__last = list_prev_rcu(__ptr); \
> >>+ likely(__ptr != __last) ? container_of(__prev, type, member) : NULL; \
> >>+ })
> >>+
> >Hi,
> >Actually I don't think you can dereference ->prev and use the standard
> >list_del_rcu because it guarantees only the ->next ptr will be valid and
> >->prev is set to LIST_POISON2.
> >IMO, you'll need something like this: https://lkml.org/lkml/2012/7/25/193
> >with the bidir_del and all that.
>
> Yeah, right, my bad - we can rely only on the ->next pointer, indeed,
> missed that part. RCU is hard :).
>
> So it'll be a lot harder to implement bond_last_slave_rcu() in a
> 'straightforward' approach.
>
> I'd rather go in the opposite direction here - i.e. drop the 'reverse'
> traversal completely, and all the use cases for bond_last_slave_rcu(). I've
> got some patches already - http://patchwork.ozlabs.org/patch/272076/ doing
> that, and hopefully will remove the whole 'backword' traversal completely
> in the future.
If it is important, it would be possible to create an RCU-protected
linked list that allowed readers to go in both directions -- mostly just
leave out the poisoning of the ->prev pointers. We do -not- want to
do this for the normal RCU-protected linked lists because the poisoning
does find bugs.
However, you would have to be quite careful with a bi-directional
RCU-protected linked list, because p->next->prev will not necessarily
be equal to p, for all the reasons that you guys listed out earlier in
this thread. So be very careful what you wish for! ;-)
Thanx, Paul
> >But in any case I complete agree with Veaceslav here. Read all the
> >documentation carefully :-)
> >
> >Cheers,
> >Nik
> >
> >> /**
> >> * list_for_each_entry_rcu - iterate over rcu list of given type
> >> * @pos: the type * to use as a loop cursor.
> >>------- END OF PATCH ------
> >>
> >>Anyway, it's up to you.
> >>
> >>Hope that helps.
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
prev parent reply other threads:[~2013-09-12 16:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 7:28 [PATCH net-next v4 1/6] bonding: simplify and use RCU protection for 3ad xmit path Ding Tianhong
2013-09-06 11:59 ` Nikolay Aleksandrov
2013-09-07 14:20 ` Veaceslav Falico
2013-09-07 14:45 ` Nikolay Aleksandrov
2013-09-07 15:03 ` Veaceslav Falico
2013-09-08 6:05 ` Ding Tianhong
2013-09-09 8:58 ` Ding Tianhong
2013-09-09 9:57 ` Veaceslav Falico
2013-09-09 14:53 ` Ding Tianhong
2013-09-09 20:17 ` Veaceslav Falico
2013-09-12 16:17 ` Paul E. McKenney [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=20130912161733.GQ3966@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=fubar@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@redhat.com \
--cc=vfalico@redhat.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.