]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'rtnetlink-allow-selected-handlers-to-run-without-rtnl'
authorDavid S. Miller <davem@davemloft.net>
Wed, 9 Aug 2017 23:57:38 +0000 (16:57 -0700)
committerDavid S. Miller <davem@davemloft.net>
Wed, 9 Aug 2017 23:57:38 +0000 (16:57 -0700)
commitd6a0c3826fef30a40d171258d788282bc8e40c35
treea3b9bf7649435c8f1c5e6b4fcfd465938ff7d395
parent1a50de52daaf166e7593426db7c767e4f272624f
parent0fe934d1eed55046a7f3a81a5bfc4d82a73c4e62
Merge branch 'rtnetlink-allow-selected-handlers-to-run-without-rtnl'

Florian Westphal says:

====================
rtnetlink: allow selected handlers to run without rtnl

Changes since v1:
 In patch 6, don't make ipv6 route handlers lockless, they all have
 assumptions on rtnl being held.  Other patches are unchanged.

The RTNL mutex is used to serialize both rtnetlink calls and
dump requests.
Its also used to protect other things such as the list of current
net namespaces.

Unfortunately RTNL mutex is a performance issue, e.g. a cpu adding an
ip address prevents other cpus from seemingly unrelated tasks such as
dumping tc classifiers or doing rtnetlink route lookups.

This patch set adds basic infrastructure to start pushing the rtnl lock
down to those places that need it, or even elide it entirely in some cases.

Subsystems can now indicate that their doit() callback can run without
RTNL mutex, such callbacks can then run in parallel.

This will obviously need a lot of followup work; all current
users need to be audited/changed to benefit from this.
Initial no-rtnl spot is netns new/getid.

We have various 'get' handlers that are also a tempting target,
however, several of these depend on rtnl mutex to prevent information
from changing while objects are being read by rtnl handlers; however,
it doesn't appear impossible to change this.

Dumps are another problem entirely, see
commit 0e88fe245c5a53e8b ("net: hold rtnl again in dump callbacks"),
this patchset doesn't touch dump requests.
====================

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