[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170809.094125.134674528726147241.davem@davemloft.net>
Date: Wed, 09 Aug 2017 09:41:25 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: fw@...len.de
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/7] rtnetlink: allow to run selected handlers
without rtnl
From: Florian Westphal <fw@...len.de>
Date: Wed, 9 Aug 2017 10:19:28 +0200
> David Miller <davem@...emloft.net> wrote:
>> From: Florian Westphal <fw@...len.de>
>> Date: Tue, 8 Aug 2017 18:02:29 +0200
>>
>> > 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)?
If the validity of change X depends upon another value Y meeting some
criteria, we test Y and then must be sure that Y doesn't change while
we go about making the change to X.
For example if I need to make sure a path to an IPV4 address exists
configured to an interface when adding a route, I must be sure that
someone can't remove that IPV4 address while I'm adding the route,
after I've checked that it does in fact exist.
This is the kind of stuff that the RTNL mutex ensures.
Powered by blists - more mailing lists