From: Veaceslav Falico <vfalico@redhat.com>
To: Ding Tianhong <dthxman@gmail.com>
Cc: Ding Tianhong <dingtianhong@huawei.com>,
Nikolay Aleksandrov <nikolay@redhat.com>,
"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: Mon, 9 Sep 2013 22:17:42 +0200 [thread overview]
Message-ID: <20130909201742.GE2048@redhat.com> (raw)
In-Reply-To: <522DE0E0.3030302@gmail.com>
On Mon, Sep 09, 2013 at 10:53:20PM +0800, Ding Tianhong wrote:
>于 2013/9/9 17:57, Veaceslav Falico 写道:
>>On Mon, Sep 09, 2013 at 04:58:29PM +0800, Ding Tianhong wrote:
>>>On 2013/9/8 14:05, Ding Tianhong wrote:
>>>
>>>Hi Veaceslav and Nik:
>>>
>>>please take a moment to reveiw the function just modify for
>>>bond_XXX_rcu,
>>>and give me some advice. thanks for the help again.:)
>>>
>>>+#define bond_first_slave_rcu(bond) \
>>>+ list_first_or_null_rcu(&(bond)->slave_list, struct slave, list);
>>>+#define bond_last_slave_rcu(bond) \
>>>+ ({struct list_head *__slave_list = &(bond)->slave_list; \
>>>+ struct list_head __rcu *__prev = \
>>>+ (*((struct list_head __rcu **)(&(__slave_list)->prev)));\
>>>+ likely(__slave_list != __prev) ? \
>>>+ container_of(__prev, struct slave, list) : NULL;})
>>
>>Please take a look at Nikolay's reply to my RCU email -
>>http://www.spinics.net/lists/netdev/msg249805.html . And mine also,
>>to his
>>email. In short - RCU doesn't guarantee ->prev, so better take the
>>approach
>>of eliminating bond_last/prev_slave completely.
>>
>yes, I see the message, the list_del_rcu will make the slave->list
>->prev = LIST_POISON2,
>the bond->slave_list will not be set to the messae, the prev will
>point a slave->list or itself,
>so I think it will be ok here, please correct me if I miss something.
Hi Ding,
Please take a look at the patchset I've just sent to net-next:
[PATCH net-next 0/26] bonding: use neighbours instead of own lists
It removes all the ->prev usage, and uses completely different primitives
for list traversal, and - *drops* the bond->slave_list and slave->list
completely. I think it would be a lot easier to RCUify bonding further
providing this patchset.
Thanks.
>
>Best Regards
>Ding
>
>>>+
>>>#define bond_is_first_slave(bond, pos) ((pos)->list.prev ==
>>>&(bond)->slave_list)
>>>#define bond_is_last_slave(bond, pos) ((pos)->list.next ==
>>>&(bond)->slave_list)
>>>
>>>@@ -93,6 +117,29 @@
>>>(bond_is_first_slave(bond, pos) ? bond_last_slave(bond) : \
>>>bond_to_slave((pos)->list.prev))
>>>
>>>+/* Since bond_first/last_slave_rcu can return NULL, these can
>>>return NULL too */
>>>+#define bond_next_slave_rcu(bond, pos) \
>>>+ ({struct list_head *__slave_list = &(bond)->slave_list; \
>>>+ struct list_head __rcu *__next = list_next_rcu(__slave_list); \
>>>+ struct list_head *__pos_list = &(pos)->list; \
>>>+ struct list_head __rcu *__pos_next = list_next_rcu(__pos_list); \
>>>+ likely(__pos_next != __slave_list) ? \
>>>+ container_of(__pos_next, struct slave, list) : \
>>>+ container_of(__next, struct slave, list); \
>>>+ })
>>
>>Nice, but can be shortened - we know that pos won't go away.
>
>OK, clean it soon.
>
>>
>>>+
>>>+#define bond_prev_slave_rcu(bond, pos) \
>>>+ ({struct list_head *__slave_list = &(bond)->slave_list; \
>>>+ struct list_head __rcu *__prev = \
>>>+ (*((struct list_head __rcu **)(&(__slave_list)->prev)));\
>>>+ struct list_head *__pos_list = &(pos)->list; \
>>>+ struct list_head __rcu *__pos_prev = (__pos_list->prev
>>>!=LIST_POISON2) ? \
>yes, the pos->list will be set to LIST_POISON2 by list_del_rcu, so I
>add a check for it, But
>take the approach of eliminating bond_last/prev_slave completely is a
>wise decision, I agree.
>
>>>+ (*((struct list_head __rcu **)(&(__pos_list)->prev))) : NULL; \
>>>+ likely(__pos_prev != __slave_list) ? \
>>>+ ((__pos_prev) ? list_entry_rcu(__pos_prev, struct slave, list)
>>>: NULL;) : \
>>>+ (list_entry_rcu(__prev, struct slave, list)); \
>>>+ })
>>
>>Same remark as above about prev.
>>
>>>+
>>>
>>>
>>>-#define bond_for_each_slave_from(bond, pos, cnt, start) \
>>>- for (cnt = 0, pos = start; pos && cnt < (bond)->slave_cnt; \
>>>- cnt++, pos = bond_next_slave(bond, pos))
>>>-
>>>+#define bond_for_each_slave_from(bond, pos, start) \
>>>+ for (pos = start; pos; (pos = bond_next_slave(bond, pos)) != start ? \
>>>+ (pos) : (pos = NULL))
>>>+
>>>+#define bond_for_each_slave_from_rcu(bond, pos, start) \
>yes, it is a little tedious. I think it could be more easier and shorter.
>
>>>+ for ({struct list_head *__start = &(start)->list; \
>>>+ struct list_head *__slave_list = &(bond)->slave_list; \
>>>+ pos = list_entry_rcu(__start, struct slave, list);}; \
>>>+ pos; \
>the only way to get out of the loop is that pos is NULL.
>>>+ {struct list_head __rcu *__next = list_next_rcu(pos->next); \
>>>+ __next != __slave_list ? \
>>>+ __next : __next = list_next_rcu(__next->next); \
>first, check whether the pos->next is the last one in the slave_list,
>if it does, get the
>first slave of the bond->slave_list.
>>>
>>>+ __next != __start ? \
>>>+ pos = list_entry_rcu(__next, struct slave, list) : \
>>>+ pos = NULL; \
>second, check whether the pos is reach the start, if not, continue,
>otherwise, the pos
>will be set to NULL, so break the loop.
>>>+ })
>>
>>Jeez, I don't even want to review it. It's too complex and too hard to
>>maintain, even if it works. Can you please make something
>>shorter/easier to
>>understand?
>>
>
>Best Regards.
>Ding
>
>>>+
>>>
>>>Best regards
>>>Ding
>>>
>>>
>>>>>--
>>>>>To unsubscribe from this list: send the line "unsubsc ribe netdev" in
>>>>>the body of a message to majordomo@vger.kernel.org
>>>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>>
>>>>.
>>>>
>>>
>>>
>>--
>>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
>>
>
next prev parent reply other threads:[~2013-09-09 20:19 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 [this message]
2013-09-12 16:17 ` Paul E. McKenney
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=20130909201742.GE2048@redhat.com \
--to=vfalico@redhat.com \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=dthxman@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@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 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).