Re: Correct usage of dev_base_lock in 2020

[Vladimir Oltean <olteanv@gmail.com>]

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@gmail.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.