From: Ding Tianhong <dthxman@gmail•com>
To: Nikolay Aleksandrov <nikolay@redhat•com>
Cc: Ding Tianhong <dingtianhong@huawei•com>,
Jay Vosburgh <fubar@us•ibm.com>,
Andy Gospodarek <andy@greyhouse•net>,
"David S. Miller" <davem@davemloft•net>,
Veaceslav Falico <vfalico@redhat•com>,
Netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH net-next v2 0/10] bonding: rebuild the lock use for bond monitor
Date: Sat, 09 Nov 2013 16:03:12 +0800 [thread overview]
Message-ID: <527DEC40.4020407@gmail.com> (raw)
In-Reply-To: <527D120E.3080706@redhat.com>
于 2013/11/9 0:32, Nikolay Aleksandrov 写道:
> On 11/08/2013 03:07 AM, Ding Tianhong wrote:
>> Now the bond slave list is not protected by bond lock, only by RTNL,
>> but the monitor still use the bond lock to protect the slave list,
>> it is useless, according to the Veaceslav's opinion, there were
>> three way to fix the protect problem:
>>
>> 1. add bond_master_upper_dev_link() and bond_upper_dev_unlink()
>> in bond->lock, but it is unsafe to call call_netdevice_notifiers()
>> in write lock.
>> 2. remove unused bond->lock for monitor function, only use the exist
>> rtnl lock(), it will take performance loss in fast path.
>> 3. use RCU to protect the slave list, of course, performance is better,
>> but in slow path, it is ignored.
>>
>> obviously the solution 1 is not fit here, I will consider the 2 and 3
>> solution. My principle is simple, if in fast path, RCU is better,
>> otherwise in slow path, both is well, but according to the Jay Vosburgh's
>> opinion, the monitor will loss performace if use RTNL to protect the all
>> slave list, so remove the bond lock and replace with RCU.
>>
>> The second problem is the curr_slave_lock for bond, it is too old and
>> unwanted in many place, because the curr_active_slave would only be
>> changed in 3 place:
>>
>> 1. enslave slave.
>> 2. release slave.
>> 3. change active slave.
>>
>> all above were already holding bond lock, RTNL and curr_slave_lock
>> together, it is tedious and no need to add so mach lock, when change
>> the curr_active_slave, you have to hold the RTNL and curr_slave_lock
>> together, and when you read the curr_active_slave, RTNL or curr_slave_lock,
>> any one of them is no problem.
>>
>> for the stability, I did not change the logic for the monitor,
>> all change is clear and simple, I have test the patch set for lockdep,
>> it work well and stability.
>>
>> v2. accept the Jay Vosburgh's opinion, remove the RTNL and replace with RCU,
>> also add some rcu function for bond use, so the patch set reach 10.
>>
>> Best Regards
>> Ding Tianhong
>>
> Hi,
> I've left my comments from a quick overview of the patches, my opinion on the
> patchset is that it wasn't tested thoroughly enough (or at all). There're
> multiple places that use a weaker compiler barrier instead of directly using
> rcu_dereference() or rcu_access_pointer(), also there're multiple places which
> can directly use macros already present in the RCU API.
>
> Cheers,
> Nik
Thanks, Nik, for overview the long patches, point out the problem, I
will review the
details which your point out and fix it.
Best Regards
Ding
>
> --
> 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-11-09 8:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-08 2:07 [PATCH net-next v2 0/10] bonding: rebuild the lock use for bond monitor Ding Tianhong
2013-11-08 6:45 ` David Miller
2013-11-12 23:26 ` Ben Hutchings
2013-11-13 9:26 ` Veaceslav Falico
2013-11-08 16:32 ` Nikolay Aleksandrov
2013-11-09 8:03 ` Ding Tianhong [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=527DEC40.4020407@gmail.com \
--to=dthxman@gmail$(echo .)com \
--cc=andy@greyhouse$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=dingtianhong@huawei$(echo .)com \
--cc=fubar@us$(echo .)ibm.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nikolay@redhat$(echo .)com \
--cc=vfalico@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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