Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5d5cf050-7de0-7bad-2407-276970222635@quicinc.com>
Date:   Tue, 22 Mar 2022 14:31:18 -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>,
        <willmcvicker@google.com>, <linux-wireless@vger.kernel.org>
CC:     Marek Szyprowski <m.szyprowski@samsung.com>
References: <0000000000009e9b7105da6d1779@google.com>
 <99eda6d1dad3ff49435b74e539488091642b10a8.camel@sipsolutions.net>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <99eda6d1dad3ff49435b74e539488091642b10a8.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/21/2022 1:07 PM, Johannes Berg wrote:
[..snip..]

>> I'm not an networking expert. So my main question is if I'm allowed to take
>> the RTNL lock inside the nl80211_vendor_cmd callbacks?
> 
> Evidently, you're not. It's interesting though, it used to be that we
> called these with the RTNL held, now we don't, and the driver you're
> using somehow "got fixed" to take it, but whoever fixed it didn't take
> into account that this is not possible?

On this point I just want to remind that prior to the locking change 
that a driver would specify on a per-vendor command basis whether or not 
it wanted the rtnl_lock to be held via NL80211_FLAG_NEED_RTNL. I'm 
guessing for the command in question the driver did not set this flag 
since the driver wanted to explicitly take the lock itself, otherwise it 
would have deadlocked on itself with the 5.10 kernel.

/jeff