netdev - Re: [PATCH net-next 0/5] bonding: patchset for rcu use in bonding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131021124144.GD692@redhat.com>
Date:	Mon, 21 Oct 2013 14:41:44 +0200
From:	Veaceslav Falico <vfalico@...hat.com>
To:	Ding Tianhong <dingtianhong@...wei.com>
Cc:	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	"David S. Miller" <davem@...emloft.net>,
	Nikolay Aleksandrov <nikolay@...hat.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/5] bonding: patchset for rcu use in bonding

On Mon, Oct 21, 2013 at 08:32:11PM +0800, Ding Tianhong wrote:
>On 2013/10/21 17:35, Veaceslav Falico wrote:
>> On Mon, Oct 21, 2013 at 05:27:51PM +0800, Ding Tianhong wrote:
>>> On 2013/10/21 17:13, Veaceslav Falico wrote:
>>>> On Mon, Oct 21, 2013 at 04:58:36PM +0800, Ding Tianhong wrote:
>>>>> Hi:
>>>>>
>>>>> The Patch Set will remove the invalid lock for bond work queue and replace it
>>>>> with rtnl lock, as read lock for bond could not protect slave list any more.
>>>>
>>>> rtnl lock is a lot more expensive than bond lock, and not only for bond,
>>>> but for all the networking stack.
>>>>
>>>> Why is the bond->lock invalid? It correctly protects slaves from being
>>>> modified concurrently.
>>>>
>>>> I don't see the point in this patchset.
>>>>
>>>
>>> yes, rtnl lock is a big lock, but I think bond->lock could not protect
>>> bond_for_each_slave any more, am I miss something?
>>
>> Why can't it protect bond_for_each_slave()?
>>
>
>bond_master_upper_dev_link() and bond_upper_dev_unlink() was only in rtnl lock,
>bond_for_each_slave may changed while loop in bond read lock, but it sees that
>nothing serious will happen yet.
>Maybe I miss something.

Even if it is unsafe to use bond_for_each_slave() while holding bond->lock
- it means that we must protect the list by locking the
bond_upper_dev_(un)link() via bond->lock, but not by removing bond->lock
from everywhere where it is now. And I'm not that sure if it's safe or not.

>
>Ding
>
>
>>>
>>> Ding
>>>
>>>>>
>>>>> Ding Tianhong (5):
>>>>>  bonding: remove bond read lock for bond_mii_monitor()
>>>>>  bonding: remove bond read lock for bond_alb_monitor()
>>>>>  bonding: remove bond read lock for bond_loadbalance_arp_mon()
>>>>>  bonding: remove bond read lock for bond_activebackup_arp_mon()
>>>>>  bonding: remove bond read lock for bond_3ad_state_machine_handler()
>>>>>
>>>>> drivers/net/bonding/bond_3ad.c  |   9 ++--
>>>>> drivers/net/bonding/bond_alb.c  |  20 ++------
>>>>> drivers/net/bonding/bond_main.c | 100 +++++++++++++---------------------------
>>>>> 3 files changed, 40 insertions(+), 89 deletions(-)
>>>>>
>>>>> --
>>>>> 1.8.2.1
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> .
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html