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

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-10-15 at 14:43 +0200, Oliver Hartkopp wrote:
> 
> On 15.10.26 14:27, Johannes Berg wrote:
> > 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.
> 
> If I got your claim correctly, I think we are solving this in this 
> net-next PR too:
> 
> https://lore.kernel.org/linux-can/20261015015336.816543-8-mkl@pengutronix.de/

I _think_ that's unrelated, but I might well not understand it
correctly. I was looking at the rtnl_unlock() portion, where that could
run a netdev todo item. Even with that change, you have

	rtnl_lock()
	lock_sock()
	...
	rtnl_unlock()
	...
	release_sock()

which looks sufficiently similar to

	rtnl_lock()
	wiphy_lock()
	rtnl_unlock()
	...
	wiphy_unlock()

that my search flagged it, but isn't really the same anyway. But I'm not
sure I understand the socket lock semantics and the socket notifier etc.
well enough that I should be commenting on this at all :)

johannes