Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <806e8714fc6b87fea44bbe6838590bde3cdfe7cd.camel@sipsolutions.net>
Subject: Re: [EXT] [RFC/RFT] cfg80211: decouple us from the RTNL
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Dedy Lansky <dlansky@codeaurora.org>,
        linux-wireless@vger.kernel.org
Cc:     'Florian Westphal' <fw@strlen.de>
Date:   Mon, 05 Aug 2019 22:41:02 +0200
In-Reply-To: <000701d54ba1$48ea2520$dabe6f60$@codeaurora.org>
References: <20190731220848.1045-1-johannes@sipsolutions.net>
         <000701d54ba1$48ea2520$dabe6f60$@codeaurora.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, 2019-08-05 at 18:20 +0300, Dedy Lansky wrote:

> > Then, we can restrict the RTNL to a few cases where we add or
> > remove interfaces and really need the added protection. Some
> > of the global list management still also uses the RTNL, since
> > we need to have it anyway for netdev management.
> > TODO:
> >  - use wiphy_lock()/wiphy_unlock() in all drivers as the code
> >    changed in mac80211 does
> 
> I guess this change breaks existing drivers because some drivers assume RTNL
> is locked when their cfg callbacks are executed. Is that correct?

It might, to some extent. Mostly though, it shouldn't really matter to
them since the actual callbacks that manipulate interfaces (add, remove,
set type) and thus require RTNL still hold the RTNL.

> Would there be any simple rules for drivers when to use each one of the
> locking API: rtnl vs wiphy vs wdev ?

I'd say RTNL only if externally required. Wiphy vs. wdev I haven't
really quite made up my mind - I'm contemplating just removing the wdev
lock since for (driver/mac80211) simplicity we'll probably not want
concurrency there anyway? Should be rare (Ben Greear will be the only
one hitting it ...) that you really need concurrency there, and
simplifies things a lot.

johannes