Re: [PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl

David Miller [off-list ref] wrote:

From: Florian Westphal <fw@strlen.de>
Date: Tue,  8 Aug 2017 18:02:29 +0200

quoted

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.

It is related if somehow the TC entries refer to IP addresses.

Someone could create something like that.

Actually I am not following.  Why would read-only accesses need rtnl
locking wrt. any other operation (provided of course rtnl lock doesn't
protect the data structure)?

quoted

Initial no-rtnl spots are ip6 fib add/del and netns new/getid.

I could see the netns stuff being ok, but IPv6 route add/del I'm
not so sure of.

[..]

There really is a hierachy of these dependencies.  Device state, up
to neighbour table state, up to protocol address state, up to routes,
   up to FIB tables, etc. etc. etc.

   I'd really like to make this operate more freely, but this is an
   extremely delicate area which has been bottled up like this for
   two decades so good luck :-)

Would you accept a v2 if i don't touch ipv6 routes for the time being?

I would then audit those again.  At the very least inet6_rtm_getroute should
be able to work without rtnl lock (i.e., use a different lock if
needed to protect vs. concurrent modifications).