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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.