public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  parent reply	other threads:[~2009-04-15 12:32 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13 18:33 [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge Jiri Pirko
2009-03-14  5:39 ` Stephen Hemminger
2009-03-14  9:49   ` Jiri Pirko
2009-03-15 23:12     ` Stephen Hemminger
2009-03-16 11:11       ` Jiri Pirko
2009-03-19  6:20         ` David Miller
2009-03-19  8:44           ` Jiri Pirko
2009-03-19 10:21             ` David Miller
2009-03-19 11:19               ` Jiri Pirko
2009-03-19  8:50           ` Patrick McHardy
2009-03-19 16:31             ` Jiri Pirko
2009-03-25 13:04 ` [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try2 Jiri Pirko
2009-03-25 13:40   ` Eric Dumazet
2009-03-25 14:39     ` Jiri Pirko
2009-03-25 15:19 ` [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try3 Jiri Pirko
2009-03-25 16:31   ` Jay Vosburgh
2009-03-25 17:44     ` Jiri Pirko
2009-03-26  0:24       ` David Miller
2009-03-26  0:34       ` Jay Vosburgh
2009-03-26 11:12     ` Jiri Pirko
2009-03-26 15:52 ` [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge -try4 Jiri Pirko
2009-03-27  7:38   ` David Miller
2009-03-27  7:46     ` Jiri Pirko
2009-03-27  7:53     ` Patrick McHardy
2009-03-27  8:41       ` Jiri Pirko
2009-03-27  8:55         ` Patrick McHardy
2009-03-27  9:47           ` Jiri Pirko
2009-03-29 20:53       ` David Miller
2009-03-30 12:04         ` Patrick McHardy
2009-03-30 12:40           ` Jiri Pirko
2009-03-30 12:47             ` Patrick McHardy
2009-03-30 12:52               ` Jiri Pirko
2009-03-30 12:58                 ` Patrick McHardy
2009-04-13  8:37 ` [PATCH 0/4] bonding: allow bond in mode balance-alb to work properly in bridge -try5 Jiri Pirko
2009-04-13  8:38   ` [PATCH 1/4] net: introduce dev_mac_address_changed Jiri Pirko
2009-04-13 14:58     ` Stephen Hemminger
2009-04-13  8:42   ` [PATCH 2/4] net: introduce a list of device addresses dev_addr_list Jiri Pirko
2009-04-13 14:49     ` Stephen Hemminger
2009-04-13 22:54       ` David Miller
2009-04-13 22:53     ` David Miller
2009-04-13  8:44   ` [PATCH 3/4] net: bridge: use device address list instead of dev_addr Jiri Pirko
2009-04-13 14:54     ` Stephen Hemminger
2009-04-14 10:15       ` Jiri Pirko
2009-04-13 22:54     ` David Miller
2009-04-13  8:46   ` [PATCH 4/4] net: bonding: add slave device addresses in mode alb Jiri Pirko
2009-04-13 14:56     ` Stephen Hemminger
2009-04-15  8:17 ` [PATCH 0/3] bonding: allow bond in mode balance-alb to work properly in bridge -try6 Jiri Pirko
2009-04-15  8:18   ` [PATCH 1/3] net: introduce a list of device addresses dev_addr_list Jiri Pirko
2009-04-15  8:26     ` Li Zefan
2009-04-15  8:29       ` Jiri Pirko
2009-04-15  8:32       ` Jiri Pirko
2009-04-15  9:21         ` David Miller
2009-04-15  9:27         ` Eric Dumazet
2009-04-15  9:31           ` David Miller
2009-04-15 10:13             ` Patrick McHardy
2009-04-15 10:15               ` David Miller
2009-04-15 10:41                 ` Patrick McHardy
2009-04-15 10:45                   ` David Miller
2009-04-15 10:47                     ` Patrick McHardy
2009-04-15 14:42               ` Jiri Pirko
2009-04-15 11:17           ` Jiri Pirko
2009-04-15 11:22             ` Patrick McHardy
2009-04-15 11:28               ` Jiri Pirko
2009-04-15 12:28             ` Eric Dumazet [this message]
2009-04-15 18:02     ` [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v2) Jiri Pirko
2009-04-15 18:54       ` Eric Dumazet
2009-04-16  8:46         ` Jiri Pirko
2009-04-17 11:57       ` [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v3) Jiri Pirko
2009-04-17 15:33         ` Stephen Hemminger
2009-04-18  7:01           ` Jiri Pirko
2009-04-18  7:35             ` Eric Dumazet
2009-04-18  7:44               ` Jiri Pirko
2009-04-18  8:06                 ` Eric Dumazet
2009-04-18  8:58         ` [PATCH 1/3] net: introduce a list of device addresses dev_addr_list (v4) Jiri Pirko
2009-04-20 16:11           ` Jiri Pirko
2009-04-23  8:09             ` Jiri Pirko
2009-05-04 11:14           ` [PATCH] net: introduce a list of device addresses dev_addr_list (v5) Jiri Pirko
2009-05-05  4:37             ` David Miller
2009-05-05  6:37               ` Jiri Pirko
2009-05-05 12:48             ` [PATCH] net: introduce a list of device addresses dev_addr_list (v6) Jiri Pirko
2009-05-05 19:27               ` David Miller
2009-05-08 22:38                 ` Stephen Hemminger
2009-05-08 23:00                   ` David Miller
2009-05-08 23:12                     ` Stephen Hemminger
2009-05-08 23:25                       ` David Miller
2009-05-08 23:29                         ` Stephen Hemminger
2009-04-15  8:21   ` [PATCH 2/3] net: bridge: use device address list instead of dev_addr Jiri Pirko
2009-05-06 14:46     ` [PATCH net-next] net: bridge: use device address list instead of dev_addr (repost) Jiri Pirko
2009-05-06 15:08       ` Eric Dumazet
2009-05-06 19:26       ` Stephen Hemminger
2009-05-07 22:03         ` David Miller
2009-04-15  8:22   ` [PATCH 3/3] net: bonding: add slave device addresses in mode alb 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=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox