Received-SPF: softfail (google.com: domain of transitioning linux-wireless-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <1c6d5a1f033ef079cef4e3aaf6ead9f946da4db0.camel@sipsolutions.net>
Subject: Re: [BUG] deadlock in nl80211_vendor_cmd
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Jeff Johnson <quic_jjohnson@quicinc.com>,
        William McVicker <willmcvicker@google.com>
Cc:     linux-wireless@vger.kernel.org,
        Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri, 25 Mar 2022 17:04:15 +0100
In-Reply-To: <2b2fa5d9-238a-81fa-8978-94bd9753b73e@quicinc.com>
References: <0000000000009e9b7105da6d1779@google.com>
         <99eda6d1dad3ff49435b74e539488091642b10a8.camel@sipsolutions.net>
         <5d5cf050-7de0-7bad-2407-276970222635@quicinc.com>
         <YjpGlRvcg72zNo8s@google.com>
         <ada45791b8792f37d4167d24a7fc440f77c2167f.camel@sipsolutions.net>
         <2b2fa5d9-238a-81fa-8978-94bd9753b73e@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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