On Fri, 2022-03-25 at 08:59 -0700, Jeff Johnson wrote: > On 3/25/2022 5:09 AM, Johannes Berg wrote: > > On Tue, 2022-03-22 at 21:58 +0000, William McVicker wrote: > > > > > > It would be nice if nl80211_vendor_cmd() could support taking the RTNL lock if > > > requested via the vendor flags. That would require moving the wiphy lock to > > > nl80211_vendor_cmds() so that it could take the RTNL and wiphy lock in the > > > correct order. Is that something you'd be open to Johannes? > > > > Not very, to be honest. If we had a good use case for it, maybe, but > > you're not even saying quite what the use case is :) > > I believe Will and I are up against the same issues. Out-of-tree Android > drivers use a large number of vendor commands to support the > requirements of the Android framework. Prior to 5.12 these vendor > commands would always be called with the rtnl lock held, and in some > cases the implementation of the vendor commands care about that, > especially when calling back into the kernel. In particular we are faced > with the issue that there are some kernel APIs that require that the > rtnl lock be held, and as a result of the lock infrastructure change we > can no longer call those APIs from vendor commands. That is a pretty > severe limitation to work around. I'm not really sure how sympathetic I am to an out-of-tree use case I cannot even see, and I'd probably consider problematic in the first place :) Your easiest option might be to just patch NL80211_FLAG_NEED_RTNL into your kernel for vendor commands and call it a day? johannes
