]> 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)
commitcd9cb3890b202f33ab4dfc287582ced6a2205137
treea3b9bf7649435c8f1c5e6b4fcfd465938ff7d395
parent078295fb9af507abce4976c6e9ff56a67da4e9a0
parent165b9117256c5432bf241fdf4637487e4af68cc8
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 2907c35ff64708065 ("net: hold rtnl again in dump callbacks"),
this patchset doesn't touch dump requests.
====================

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