From: David S. Miller Date: Wed, 9 Aug 2017 23:57:38 +0000 (-0700) Subject: Merge branch 'rtnetlink-allow-selected-handlers-to-run-without-rtnl' X-Git-Tag: v4.14-rc1~130^2~308 X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=commitdiff_plain;h=cd9cb3890b202f33ab4dfc287582ced6a2205137;p=linux.git 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 --- cd9cb3890b202f33ab4dfc287582ced6a2205137