Re: Correct usage of dev_base_lock in 2020

Jakub Kicinski
2020-11-30T18:15:07Z

On Mon, 30 Nov 2020 11:41:10 +0100 Eric Dumazet wrote:
> > So dev_base_lock dates back to the Big Kernel Lock breakup back in Linux 2.4
> > (ie before my time). The time has come to get rid of it.
> >
> > The use is sysfs is because could be changed to RCU. There have been issues
> > in the past with sysfs causing lock inversions with the rtnl mutex, that
> > is why you will see some trylock code there.
> >
> > My guess is that dev_base_lock readers exist only because no one bothered to do
> > the RCU conversion.
>
> I think we did, a long time ago.
>
> We took care of all ' fast paths' already.
>
> Not sure what is needed, current situation does not bother me at all ;)

Perhaps Vladimir has a plan to post separately about it (in that case
sorry for jumping ahead) but the initial problem was procfs which is
(hopefully mostly irrelevant by now, and) taking the RCU lock only
therefore forcing drivers to have re-entrant, non-sleeping
.ndo_get_stats64 implementations.