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

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
> 
> Also,
> I hope we could remove the long comment in __rtnl_unlock().

So I sent my next PR, and we could therefore do that now. I also checked
across the other places in the tree, and isotp_release() was the only
one that seems to do something similar, keeping a socket pinned around
rtnl_unlock(), but I don't think that could cause a similar problem.

I was going to send a patch, but then I didn't (and am sending this mail
instead) because I'm not really sure what we should do with the WARN_ON.

On the one hand, it's no longer strictly _necessary_, code that queues a
work item (unregistered a netdev) and then calls __rtnl_unlock()
explicitly wouldn't have any expectation of completing that soon.

On the other hand, the next random code that acquired the rtnl and then
unlocked it would suddenly have to do the unregistration work for some
other code and it'd be accounted to that thread and cause latency there
(not that it can have much expectation on latency while using the rtnl
...), so in some way the WARN_ON() still seems justified?

Anyway, the cfg80211 bits are gone once the PR lands, so you can remove
the comment (and possibly WARN_ON) whichever way you prefer :)

johannes