]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'bond_lock_removal'
authorDavid S. Miller <davem@davemloft.net>
Wed, 10 Sep 2014 00:31:43 +0000 (17:31 -0700)
committerDavid S. Miller <davem@davemloft.net>
Wed, 10 Sep 2014 00:31:43 +0000 (17:31 -0700)
commit4854b70a98b5a92e97ee21b066a9a22699c30f06
tree597c6a74e401afdb18686a3ccf71abc46fc21cbf
parent5bcda6a5eff013eebe70289fc43f95fa83cd12e6
parent0546cf8ff467296527506f7cd30552f9b00f81b5
Merge branch 'bond_lock_removal'

Nikolay Aleksandrov says:

====================
bonding: get rid of bond->lock

This patch-set removes the last users of bond->lock and converts the places
that needed it for sync to use curr_slave_lock or RCU as appropriate.
I've run this with lockdep and have stress-tested it via loading/unloading
and enslaving/releasing in parallel while outputting bond's proc, I didn't
see any issues. Please pay special attention to the procfs change, I've
done about an hour of stress-testing on it and have checked that the event
that causes the bonding to delete its proc entry (NETDEV_UNREGISTER) is
called before ndo_uninit() and the freeing of the dev so any readers will
sync with that. Also ran sparse checks and there were no splats.

v2: Add patch 0001/cxgb4 bond->lock removal, RTNL should be held in the
    notifier call, the other patches are the same. Also tested with
    allmodconfig to make sure there're no more users of bond->lock.
Changes from the RFC:
 use RCU in procfs instead of RTNL since RTNL might lead to a deadlock with
 unloading and also is much slower. The bond destruction syncs with proc
 via the proc locks. There's one new patch that converts primary_slave to
 use RCU as it was necessary to fix a longstanding bugs in sysfs and
 procfs and to make it easy to migrate bond's procfs to RCU. And of course
 rebased on top of net-next current.

This is the first patch-set in a series that should simplify the bond's
locking requirements and will make it easier to define the locking
conditions necessary for the various paths. The goal is to rely on RTNL
and rcu alone, an extra lock would be needed in a few special cases that
would be documented very well.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>