Re: [GIT PULL] wireless-next-2026-10-07

[Johannes Berg <johannes@sipsolutions.net>]

Hi Kuniyuki,

On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
> On Wed, Oct 7, 2026 at 4:36 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > 
> > On Wed,  7 Oct 2026 22:57:00 +0200 Johannes Berg wrote:
> > > Nothing much going on in wireless-next. However, next time
> > > I hope to land my RTNL-redux series which will (almost)
> > > completely wean the wireless stack off the RTNL, except in
> > > places where we need it for netdev register/unregister/etc.
> 
> That's great !
> 
> We saw a wifi driver holding RTNL long on Android.

Well, _that_ mostly shouldn't have happened for a long time (since
5.12), though I actually learned yesterday that some android drivers
went to implement things with private ioctls because they (thought they)
needed the RTNL ... so, Android, take with a bag of salt.

> Also, I hope we could remove the long comment in __rtnl_unlock().

Couldn't we remove that today, by just __rtnl_unlock() in that place in
cfg80211? But it's not exported, for good reason, presumably.

But that's also irrelevant, because indeed after my patchset cfg80211
doesn't do that any more:
https://lore.kernel.org/linux-wireless/20261006100655.2687533-21-johannes@sipsolutions.net/

> > > I need to see what's going on with the per-netns mutex now,
> > > can we already use that instead?
> 
> Do you mean moving net->rtnl_mutex out of Kconfig ?

I have no idea what I'm talking about ;-)

> Recently, I've been converting the first-class rtnetlink handlers
> with dedicated locks, but others not worth the effort will simply
> replace rtnl_lock() with rtnl_net_lock().
> 
> rtnl_net_lock() still acquires rtnl_lock(), but if we always compile
> net->rtnl_mutex, using __rtnl_net_lock() for the latter should be
> okay.

OK so I (likely naively) thought the idea was that most things like
netdev registration/unregistration eventually move to rtnl_net_lock()?
Here are the places that still take RTNL in wifi after the patchset
above:

 - suspend/resume (not entirely sure - it goes to hw restart maybe)
 - hw restart (can unregister netdevs on failures)
 - rate control init in mac80211 (but that can be removed easily)
 - netdev registration
 - netdev unregistration
 - rfkill, to call dev_close()
 - wiphy registration/unregistration (might be possible to disentangle
   now)
 - network namespace destruction/exit
 - wiphy naming, but that can move to cfg80211_mtx now
 - some netlink dumps (related to the naming?)
 - testmode/vendor ... I guess we can't get rid of that,
   but no upstream drivers should have much here
 - interface/wdev start/stop
 - netns moves

(and a couple of places I should just fix).

So mostly that's relatively short-lived (like the wiphy naming stuff) or
related to network/netns maintenance where I'm not sure.

Thanks!

johannes

> 
> 
> > 
> > That's a Kuniyuki question (cced). I've been trying to move
> > HW drivers out of rtnl_lock and under netdev->lock.
> > Most of the rtnl_lock contention I've seen in prod at Meta
> > is in init_net
> 
> FWIW, I've still seen contention while creating/removing containers.