From: Eric Dumazet <dada1@cosmosbay.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: ivecera@redhat.com, fubar@us.ibm.com, netdev@vger.kernel.org,
bridge@lists.linux-foundation.org, Li Zefan <lizf@cn.fujitsu.com>,
linux-kernel@vger.kernel.org, mschmidt@redhat.com,
bonding-devel@lists.sourceforge.net, jgarzik@pobox.com,
davem@davemloft.net
Subject: Re: [Bridge] [PATCH 1/3] net: introduce a list of device addresses dev_addr_list
Date: Wed, 15 Apr 2009 14:28:37 +0200 [thread overview]
Message-ID: <49E5D2F5.8060108@cosmosbay.com> (raw)
In-Reply-To: <20090415111724.GG21342@psychotron.englab.brq.redhat.com>
Jiri Pirko a écrit :
> Wed, Apr 15, 2009 at 11:27:50AM CEST, dada1@cosmosbay.com wrote:
>> kzalloc(max(sizeof(*ha), L1_CACHE_SIZE)) is thus higly recommended here.
> You mean PAGE_CACHE_SIZE? I think that would be little wasting... But I see your
> point...
No, I meant L1_CACHE_BYTES (usually 64 bytes on x86), I always confuse BYTES and SIZE on this one...
>>> + list_for_each_entry(ha, list, list) {
>>> + if (i++ != ignore_index &&
>>> + !memcmp(ha->addr, addr, addr_len)) {
>>> + if (--ha->refcount)
>>> + return 0;
>>> + list_del_rcu(&ha->list);
>>> + synchronize_rcu();
>> Oh well... I'm pretty sure this synchronize_rcu() call can be avoided,
>> dont you think ? Check kfree_rcu() or equivalent, as it seems not yet
>> included in current kernels...
>>
> Well once kfree_rcu() will be in the tree I will be happy to replace this.
If kfree_rcu() not yet available, please use a regular call_rcu() construct
(thus adding a struct rcu_head rcu; in struct netdev_hw_addr)
If you delete say 10 addresses on a device, while RTNL (or other lock) locked,
that means a lot of calls to synchronize_rcu() and a long lock hold time.
>
>>> + kfree(ha);
>>> + return 0;
>>> + }
>>> + }
>>> + return -ENOENT;
>
> <snip>
>
>>> + err = __hw_addr_add(&dev->dev_addr_list, addr, sizeof(*addr));
>>> + if (!err) {
>>> + /*
>>> + * Get the first (previously created) address from the list
>>> + * and set dev_addr pointer to this location.
>>> + */
>>> + rcu_read_lock();
>> locking is not correct or unnecessary
>
> Agree that here locking is not necessary, but I wanted to stay consistent to the
> rest of the code. Do you think I should remove locking here entirely?
Yes, it is very confusing for reviewers because we feel patch submiter
is not comfortable with locking rules.
Check for example dev_add_pack() in net/core/dev.c : It uses list_add_rcu()
but as it also uses a regular spinlock, there is no point using rcu_read_lock().
void dev_add_pack(struct packet_type *pt)
{
int hash;
spin_lock_bh(&ptype_lock);
if (pt->type == htons(ETH_P_ALL))
list_add_rcu(&pt->list, &ptype_all);
else {
hash = ntohs(pt->type) & PTYPE_HASH_MASK;
list_add_rcu(&pt->list, &ptype_base[hash]);
}
spin_unlock_bh(&ptype_lock);
}
Please note list_add_rcu() (and/or rcu_assign_pointer()) are still needed to protect
readers that dont use the spinlock at all.
If you use fact that RTNL is locked when calling your code, you could add
ASSERT_RTNL();
at strategic points so that this assertion can be checked at runtime.
(but Patrick & David wrote that you should not assume RTNL, so you probably need another lock...)
Thank you
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
jgarzik@pobox.com, davem@davemloft.net,
shemminger@linux-foundation.org,
bridge@lists.linux-foundation.org, fubar@us.ibm.com,
bonding-devel@lists.sourceforge.net, kaber@trash.net,
mschmidt@redhat.com, ivecera@redhat.com
Subject: Re: [PATCH 1/3] net: introduce a list of device addresses dev_addr_list
Date: Wed, 15 Apr 2009 14:28:37 +0200 [thread overview]
Message-ID: <49E5D2F5.8060108@cosmosbay.com> (raw)
In-Reply-To: <20090415111724.GG21342@psychotron.englab.brq.redhat.com>
Jiri Pirko a écrit :
> Wed, Apr 15, 2009 at 11:27:50AM CEST, dada1@cosmosbay.com wrote:
>> kzalloc(max(sizeof(*ha), L1_CACHE_SIZE)) is thus higly recommended here.
> You mean PAGE_CACHE_SIZE? I think that would be little wasting... But I see your
> point...
No, I meant L1_CACHE_BYTES (usually 64 bytes on x86), I always confuse BYTES and SIZE on this one...
>>> + list_for_each_entry(ha, list, list) {
>>> + if (i++ != ignore_index &&
>>> + !memcmp(ha->addr, addr, addr_len)) {
>>> + if (--ha->refcount)
>>> + return 0;
>>> + list_del_rcu(&ha->list);
>>> + synchronize_rcu();
>> Oh well... I'm pretty sure this synchronize_rcu() call can be avoided,
>> dont you think ? Check kfree_rcu() or equivalent, as it seems not yet
>> included in current kernels...
>>
> Well once kfree_rcu() will be in the tree I will be happy to replace this.
If kfree_rcu() not yet available, please use a regular call_rcu() construct
(thus adding a struct rcu_head rcu; in struct netdev_hw_addr)
If you delete say 10 addresses on a device, while RTNL (or other lock) locked,
that means a lot of calls to synchronize_rcu() and a long lock hold time.
>
>>> + kfree(ha);
>>> + return 0;
>>> + }
>>> + }
>>> + return -ENOENT;
>
> <snip>
>
>>> + err = __hw_addr_add(&dev->dev_addr_list, addr, sizeof(*addr));
>>> + if (!err) {
>>> + /*
>>> + * Get the first (previously created) address from the list
>>> + * and set dev_addr pointer to this location.
>>> + */
>>> + rcu_read_lock();
>> locking is not correct or unnecessary
>
> Agree that here locking is not necessary, but I wanted to stay consistent to the
> rest of the code. Do you think I should remove locking here entirely?
Yes, it is very confusing for reviewers because we feel patch submiter
is not comfortable with locking rules.
Check for example dev_add_pack() in net/core/dev.c : It uses list_add_rcu()
but as it also uses a regular spinlock, there is no point using rcu_read_lock().
void dev_add_pack(struct packet_type *pt)
{
int hash;
spin_lock_bh(&ptype_lock);
if (pt->type == htons(ETH_P_ALL))
list_add_rcu(&pt->list, &ptype_all);
else {
hash = ntohs(pt->type) & PTYPE_HASH_MASK;
list_add_rcu(&pt->list, &ptype_base[hash]);
}
spin_unlock_bh(&ptype_lock);
}
Please note list_add_rcu() (and/or rcu_assign_pointer()) are still needed to protect
readers that dont use the spinlock at all.
If you use fact that RTNL is locked when calling your code, you could add
ASSERT_RTNL();
at strategic points so that this assertion can be checked at runtime.
(but Patrick & David wrote that you should not assume RTNL, so you probably need another lock...)
Thank you
next prev parent reply other threads:[~2009-04-15 12:28 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-13 18:33 [Bridge] [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge Jiri Pirko
2009-03-13 18:33 ` Jiri Pirko
2009-03-14 5:39 ` [Bridge] " Stephen Hemminger
2009-03-14 5:39 ` Stephen Hemminger
2009-03-14 9:49 ` [Bridge] " Jiri Pirko
2009-03-14 9:49 ` Jiri Pirko
2009-03-15 23:12 ` [Bridge] " Stephen Hemminger
2009-03-15 23:12 ` Stephen Hemminger
2009-03-16 11:11 ` [Bridge] " Jiri Pirko
2009-03-16 11:11 ` Jiri Pirko
2009-03-19 6:20 ` [Bridge] " David Miller
2009-03-19 6:20 ` David Miller
2009-03-19 8:44 ` [Bridge] " Jiri Pirko
2009-03-19 8:44 ` Jiri Pirko
2009-03-19 10:21 ` [Bridge] " David Miller
2009-03-19 10:21 ` David Miller
2009-03-19 11:19 ` [Bridge] " Jiri Pirko
2009-03-19 11:19 ` Jiri Pirko
2009-03-19 8:50 ` [Bridge] " Patrick McHardy
2009-03-19 8:50 ` Patrick McHardy
2009-03-19 16:31 ` [Bridge] " Jiri Pirko
2009-03-19 16:31 ` Jiri Pirko
2009-03-25 13:04 ` [Bridge] [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try2 Jiri Pirko
2009-03-25 13:04 ` Jiri Pirko
2009-03-25 13:40 ` [Bridge] " Eric Dumazet
2009-03-25 13:40 ` Eric Dumazet
2009-03-25 14:39 ` [Bridge] " Jiri Pirko
2009-03-25 14:39 ` Jiri Pirko
2009-03-25 15:19 ` [Bridge] [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try3 Jiri Pirko
2009-03-25 15:19 ` Jiri Pirko
2009-03-25 16:31 ` [Bridge] " Jay Vosburgh
2009-03-25 16:31 ` Jay Vosburgh
2009-03-25 17:44 ` [Bridge] " Jiri Pirko
2009-03-25 17:44 ` Jiri Pirko
2009-03-26 0:24 ` [Bridge] " David Miller
2009-03-26 0:24 ` David Miller
2009-03-26 0:34 ` [Bridge] " Jay Vosburgh
2009-03-26 0:34 ` Jay Vosburgh
2009-03-26 11:12 ` [Bridge] " Jiri Pirko
2009-03-26 11:12 ` Jiri Pirko
2009-03-26 15:52 ` [Bridge] [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try4 Jiri Pirko
2009-03-26 15:52 ` Jiri Pirko
2009-03-27 7:38 ` [Bridge] " David Miller
2009-03-27 7:38 ` David Miller
2009-03-27 7:46 ` [Bridge] " Jiri Pirko
2009-03-27 7:46 ` Jiri Pirko
2009-03-27 7:53 ` [Bridge] " Patrick McHardy
2009-03-27 7:53 ` Patrick McHardy
2009-03-27 8:41 ` [Bridge] " Jiri Pirko
2009-03-27 8:41 ` Jiri Pirko
2009-03-27 8:55 ` [Bridge] " Patrick McHardy
2009-03-27 8:55 ` Patrick McHardy
2009-03-27 9:47 ` [Bridge] " Jiri Pirko
2009-03-27 9:47 ` Jiri Pirko
2009-03-29 20:53 ` [Bridge] " David Miller
2009-03-29 20:53 ` David Miller
2009-03-30 12:04 ` [Bridge] " Patrick McHardy
2009-03-30 12:04 ` Patrick McHardy
2009-03-30 12:40 ` [Bridge] " Jiri Pirko
2009-03-30 12:40 ` Jiri Pirko
2009-03-30 12:47 ` [Bridge] " Patrick McHardy
2009-03-30 12:47 ` Patrick McHardy
2009-03-30 12:52 ` [Bridge] " Jiri Pirko
2009-03-30 12:52 ` Jiri Pirko
2009-03-30 12:58 ` [Bridge] " Patrick McHardy
2009-03-30 12:58 ` Patrick McHardy
2009-05-26 15:17 ` [Bridge] [PATCH net-next] bonding: allow bond in mode balance-alb to work properly in bridge -try4.1 Jiri Pirko
2009-05-26 16:32 ` Andy Gospodarek
2009-05-27 8:25 ` Jiri Pirko
2009-05-26 16:59 ` Eric Dumazet
2009-05-27 8:42 ` Jiri Pirko
2009-05-27 13:53 ` [Bridge] [PATCH net-next] bonding: allow bond in mode balance-alb to work properly in bridge -try4.2 Jiri Pirko
2009-05-27 14:39 ` Eric Dumazet
2009-05-28 9:57 ` Jiri Pirko
2009-05-28 11:05 ` [Bridge] [PATCH net-next] bonding: allow bond in mode balance-alb to work properly in bridge -try4.3 Jiri Pirko
2009-05-28 11:41 ` Eric Dumazet
2009-05-29 8:52 ` David Miller
2009-05-28 12:11 ` Andy Gospodarek
2009-04-13 8:37 ` [Bridge] [PATCH 0/4] bonding: allow bond in mode balance-alb to work properly in bridge -try5 Jiri Pirko
2009-04-13 8:37 ` Jiri Pirko
2009-04-13 8:38 ` [Bridge] [PATCH 1/4] net: introduce dev_mac_address_changed Jiri Pirko
2009-04-13 8:38 ` Jiri Pirko
2009-04-13 14:58 ` [Bridge] " Stephen Hemminger
2009-04-13 14:58 ` Stephen Hemminger
2009-04-13 8:42 ` [Bridge] [PATCH 2/4] net: introduce a list of device addresses dev_addr_list Jiri Pirko
2009-04-13 8:42 ` Jiri Pirko
2009-04-13 14:49 ` [Bridge] " Stephen Hemminger
2009-04-13 14:49 ` Stephen Hemminger
2009-04-13 22:54 ` [Bridge] " David Miller
2009-04-13 22:54 ` David Miller
2009-04-13 22:53 ` [Bridge] " David Miller
2009-04-13 22:53 ` David Miller
2009-04-13 8:44 ` [Bridge] [PATCH 3/4] net: bridge: use device address list instead of dev_addr Jiri Pirko
2009-04-13 8:44 ` Jiri Pirko
2009-04-13 14:54 ` [Bridge] " Stephen Hemminger
2009-04-13 14:54 ` Stephen Hemminger
2009-04-14 10:15 ` [Bridge] " Jiri Pirko
2009-04-14 10:15 ` Jiri Pirko
2009-04-13 22:54 ` [Bridge] " David Miller
2009-04-13 22:54 ` David Miller
2009-04-13 8:46 ` [Bridge] [PATCH 4/4] net: bonding: add slave device addresses in mode alb Jiri Pirko
2009-04-13 8:46 ` Jiri Pirko
2009-04-13 14:56 ` [Bridge] " Stephen Hemminger
2009-04-13 14:56 ` Stephen Hemminger
2009-04-15 8:17 ` [Bridge] [PATCH 0/3] bonding: allow bond in mode balance-alb to work properly in bridge -try6 Jiri Pirko
2009-04-15 8:17 ` Jiri Pirko
2009-04-15 8:18 ` [Bridge] [PATCH 1/3] net: introduce a list of device addresses dev_addr_list Jiri Pirko
2009-04-15 8:18 ` Jiri Pirko
2009-04-15 8:26 ` [Bridge] " Li Zefan
2009-04-15 8:26 ` Li Zefan
2009-04-15 8:29 ` [Bridge] " Jiri Pirko
2009-04-15 8:29 ` Jiri Pirko
2009-04-15 8:32 ` [Bridge] " Jiri Pirko
2009-04-15 8:32 ` Jiri Pirko
2009-04-15 9:21 ` [Bridge] " David Miller
2009-04-15 9:21 ` David Miller
2009-04-15 9:27 ` [Bridge] " Eric Dumazet
2009-04-15 9:27 ` Eric Dumazet
2009-04-15 9:31 ` [Bridge] " David Miller
2009-04-15 9:31 ` David Miller
2009-04-15 10:13 ` [Bridge] " Patrick McHardy
2009-04-15 10:13 ` Patrick McHardy
2009-04-15 10:15 ` [Bridge] " David Miller
2009-04-15 10:15 ` David Miller
2009-04-15 10:41 ` [Bridge] " Patrick McHardy
2009-04-15 10:41 ` Patrick McHardy
2009-04-15 10:45 ` [Bridge] " David Miller
2009-04-15 10:45 ` David Miller
2009-04-15 10:47 ` [Bridge] " Patrick McHardy
2009-04-15 10:47 ` Patrick McHardy
2009-04-15 14:42 ` [Bridge] " Jiri Pirko
2009-04-15 14:42 ` Jiri Pirko
2009-04-15 11:17 ` [Bridge] " Jiri Pirko
2009-04-15 11:17 ` Jiri Pirko
2009-04-15 11:22 ` [Bridge] " Patrick McHardy
2009-04-15 11:22 ` Patrick McHardy
2009-04-15 11:28 ` [Bridge] " Jiri Pirko
2009-04-15 11:28 ` Jiri Pirko
2009-04-15 12:28 ` Eric Dumazet [this message]
2009-04-15 12:28 ` Eric Dumazet
2009-04-15 18:02 ` [Bridge] [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v2) Jiri Pirko
2009-04-15 18:02 ` Jiri Pirko
2009-04-15 18:54 ` [Bridge] " Eric Dumazet
2009-04-15 18:54 ` Eric Dumazet
2009-04-16 8:46 ` [Bridge] " Jiri Pirko
2009-04-16 8:46 ` Jiri Pirko
2009-04-17 11:57 ` [Bridge] [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v3) Jiri Pirko
2009-04-17 11:57 ` Jiri Pirko
2009-04-17 15:33 ` [Bridge] " Stephen Hemminger
2009-04-17 15:33 ` Stephen Hemminger
2009-04-18 7:01 ` [Bridge] " Jiri Pirko
2009-04-18 7:01 ` Jiri Pirko
2009-04-18 7:35 ` [Bridge] " Eric Dumazet
2009-04-18 7:35 ` Eric Dumazet
2009-04-18 7:44 ` [Bridge] " Jiri Pirko
2009-04-18 7:44 ` Jiri Pirko
2009-04-18 8:06 ` [Bridge] " Eric Dumazet
2009-04-18 8:06 ` Eric Dumazet
2009-04-18 8:58 ` [Bridge] [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v4) Jiri Pirko
2009-04-18 8:58 ` Jiri Pirko
2009-04-20 16:11 ` [Bridge] " Jiri Pirko
2009-04-20 16:11 ` Jiri Pirko
2009-04-23 8:09 ` [Bridge] " Jiri Pirko
2009-04-23 8:09 ` Jiri Pirko
2009-04-23 15:58 ` [Bridge] [Bonding-devel] " Stephen Hemminger
2009-04-24 21:26 ` Jiri Pirko
2009-05-04 11:14 ` [Bridge] [PATCH] net: introduce a list of device addresses dev_addr_list (v5) Jiri Pirko
2009-05-04 11:14 ` Jiri Pirko
2009-05-05 4:37 ` [Bridge] " David Miller
2009-05-05 4:37 ` David Miller
2009-05-05 6:37 ` [Bridge] " Jiri Pirko
2009-05-05 6:37 ` Jiri Pirko
2009-05-05 12:48 ` [Bridge] [PATCH] net: introduce a list of device addresses dev_addr_list (v6) Jiri Pirko
2009-05-05 12:48 ` Jiri Pirko
2009-05-05 19:27 ` [Bridge] " David Miller
2009-05-05 19:27 ` David Miller
2009-05-08 22:38 ` [Bridge] " Stephen Hemminger
2009-05-08 22:38 ` Stephen Hemminger
2009-05-08 23:00 ` [Bridge] " David Miller
2009-05-08 23:00 ` David Miller
2009-05-08 23:12 ` [Bridge] " Stephen Hemminger
2009-05-08 23:12 ` Stephen Hemminger
2009-05-08 23:25 ` [Bridge] " David Miller
2009-05-08 23:25 ` David Miller
2009-05-08 23:29 ` [Bridge] " Stephen Hemminger
2009-05-08 23:29 ` Stephen Hemminger
2009-04-15 8:21 ` [Bridge] [PATCH 2/3] net: bridge: use device address list instead of dev_addr Jiri Pirko
2009-04-15 8:21 ` Jiri Pirko
2009-05-06 14:46 ` [Bridge] [PATCH net-next] net: bridge: use device address list instead of dev_addr (repost) Jiri Pirko
2009-05-06 14:46 ` Jiri Pirko
2009-05-06 15:08 ` [Bridge] " Eric Dumazet
2009-05-06 15:08 ` Eric Dumazet
2009-05-06 19:26 ` [Bridge] " Stephen Hemminger
2009-05-06 19:26 ` Stephen Hemminger
2009-05-07 22:03 ` [Bridge] " David Miller
2009-05-07 22:03 ` David Miller
2009-04-15 8:22 ` [Bridge] [PATCH 3/3] net: bonding: add slave device addresses in mode alb Jiri Pirko
2009-04-15 8:22 ` Jiri Pirko
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=49E5D2F5.8060108@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=ivecera@redhat.com \
--cc=jgarzik@pobox.com \
--cc=jpirko@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
/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.