On Mon, 2019-08-05 at 18:20 +0300, Dedy Lansky wrote: > > Then, we can restrict the RTNL to a few cases where we add or > > remove interfaces and really need the added protection. Some > > of the global list management still also uses the RTNL, since > > we need to have it anyway for netdev management. > > TODO: > > - use wiphy_lock()/wiphy_unlock() in all drivers as the code > > changed in mac80211 does > > I guess this change breaks existing drivers because some drivers assume RTNL > is locked when their cfg callbacks are executed. Is that correct? It might, to some extent. Mostly though, it shouldn't really matter to them since the actual callbacks that manipulate interfaces (add, remove, set type) and thus require RTNL still hold the RTNL. > Would there be any simple rules for drivers when to use each one of the > locking API: rtnl vs wiphy vs wdev ? I'd say RTNL only if externally required. Wiphy vs. wdev I haven't really quite made up my mind - I'm contemplating just removing the wdev lock since for (driver/mac80211) simplicity we'll probably not want concurrency there anyway? Should be rare (Ben Greear will be the only one hitting it ...) that you really need concurrency there, and simplifies things a lot. johannes
