Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <2b2fa5d9-238a-81fa-8978-94bd9753b73e@quicinc.com>
Date:   Fri, 25 Mar 2022 08:59:06 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [BUG] deadlock in nl80211_vendor_cmd
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        William McVicker <willmcvicker@google.com>
CC:     <linux-wireless@vger.kernel.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>
References: <0000000000009e9b7105da6d1779@google.com>
 <99eda6d1dad3ff49435b74e539488091642b10a8.camel@sipsolutions.net>
 <5d5cf050-7de0-7bad-2407-276970222635@quicinc.com>
 <YjpGlRvcg72zNo8s@google.com>
 <ada45791b8792f37d4167d24a7fc440f77c2167f.camel@sipsolutions.net>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <ada45791b8792f37d4167d24a7fc440f77c2167f.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

/jeff