netdev - Re: Correct usage of dev_base

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]

Message-ID: <20201130203640.3vspyoswd5r5n3es@skbuf>
Date:   Mon, 30 Nov 2020 22:36:40 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Jiri Benc <jbenc@...hat.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Correct usage of dev_base_lock in 2020

On Mon, Nov 30, 2020 at 09:29:15PM +0100, Eric Dumazet wrote:
> On Mon, Nov 30, 2020 at 9:26 PM Vladimir Oltean <olteanv@...il.com> wrote:
> >
> > On Mon, Nov 30, 2020 at 12:21:29PM -0800, Stephen Hemminger wrote:
> > > if device is in a private list (in bond device), the way to handle
> > > this is to use dev_hold() to keep a ref count.
> >
> > Correct, dev_hold is a tool that can also be used. But it is a tool that
> > does not solve the general problem - only particular ones. See the other
> > interesting callers of dev_get_stats in parisc, appldata, net_failover.
> > We can't ignore that RTNL is used for write-side locking forever.
>
> dev_base_lock is used to protect the list of devices (eg for /proc/net/devices),
> so this will need to be replaced by something. dev_hold() won't
> protect the 'list' from changing under us.

Yes, so as I was saying. I was thinking that I could add another locking
mechanism, such as struct net::netdev_lists_mutex or something like that.
A mutex does not really have a read-side and a write-side, but logically
speaking, this one would. So as long as I take this mutex from all places
that also take the write-side of dev_base_lock, I should get equivalent
semantics on the read side as if I were to take the RTNL mutex. I don't
even need to convert all instances of RTNL-holding, that could be spread
out over a longer period of time. It's just that I can hold this new
netdev_lists_mutex in new code that calls for_each_netdev and friends,
and doesn't otherwise need the RTNL.

Again, the reason why I opened this thread was that I wanted to get rid
of dev_base_lock first, before I introduced the struct net::netdev_lists_mutex.