From: Johannes Berg <johannes@sipsolutions.net>
To: Dedy Lansky <dlansky@codeaurora.org>, linux-wireless@vger.kernel.org
Cc: 'Florian Westphal' <fw@strlen.de>
Subject: Re: [EXT] [RFC/RFT] cfg80211: decouple us from the RTNL
Date: Mon, 05 Aug 2019 22:41:02 +0200 [thread overview]
Message-ID: <806e8714fc6b87fea44bbe6838590bde3cdfe7cd.camel@sipsolutions.net> (raw)
In-Reply-To: <000701d54ba1$48ea2520$dabe6f60$@codeaurora.org>
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
prev parent reply other threads:[~2019-08-05 20:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 22:08 [RFC/RFT] cfg80211: decouple us from the RTNL Johannes Berg
2019-08-01 3:59 ` Sid Hayn
2019-08-05 15:20 ` [EXT] " Dedy Lansky
2019-08-05 20:41 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=806e8714fc6b87fea44bbe6838590bde3cdfe7cd.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=dlansky@codeaurora.org \
--cc=fw@strlen.de \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).