From: Johannes Berg <johannes@sipsolutions.net>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: question for mac80211 driver maintainers - RCU usage in drivers
Date: Wed, 04 Dec 2013 23:23:49 +0100 [thread overview]
Message-ID: <1386195829.7669.3.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1409469.QTj73PAUiY@blech> (sfid-20131204_231634_444573_6B69F370)
On Wed, 2013-12-04 at 23:16 +0100, Christian Lamparter wrote:
> > Is there any other driver that assumes it is safe to delete a station
> > pointer in the sta_state callback and not use synchronize_rcu()? From
> > looking at the code, I don't see any, but I can't really be sure that
> > everyone uses __rcu annotations correctly ... :)
> No, carl9170 doesn't use sta_state but it uses sta_remove.
Yeah, I actually saw this. But I think you use it for aggregation
sessions only? And the code didn't look like it could still get to the
station pointer after it was removed with sta_remove() callback, but I
may be wrong.
> I'm curious: how you would achieve this feat? After all, mac80211's
> tx- and rx-paths currently relies on RCU protected station pointers
> too (and all that goes along with it. e.g.: ampdu sessions, keys, ...)?
Oh, that'll stay. But right now we do *two* things:
a) synchronize_net() to protect against mac80211
b) rcu_barrier() stuff (see commit b22cfcfca) to protect again
It seems to me if the drivers don't assume RCU grace period after
sta_state/sta_remove, then the second one can go away.
> > PS: I'll probably have to add another callback "sta going away before
> > RCU" so you can invalidate pointers there ... otherwise I'd have to
> > synchronize_rcu() in iwlmvm which would kinda defeat the purpose.
> hm, invalidating ampdu sessions is going to be tricky isn't it?
> But ok, some time ago I played around with moving the complicated
> amdpu scheduler of carl9170 into the (single-threaded) firmware.
> So large parts of carl9170's code which uses rcu in this context would
> become "unnecessary".
>
> I didn't merge the patch - since there was no obvious benefit - but
> I still have them and they can be revived if needed.
No, don't worry. I'm keeping the aggregation session guarantees even,
right now I'm not touching that so each aggregation session still uses
synchronize_rcu() etc.
johannes
next prev parent reply other threads:[~2013-12-04 22:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 21:30 question for mac80211 driver maintainers - RCU usage in drivers Johannes Berg
2013-12-04 22:16 ` Christian Lamparter
2013-12-04 22:23 ` Johannes Berg [this message]
2013-12-04 22:47 ` Christian Lamparter
2013-12-04 22:51 ` Johannes Berg
2013-12-05 12:35 ` [PATCH 0/8] mac80211: speed up station cleanup/AP shutdown Johannes Berg
2013-12-05 12:35 ` [PATCH 1/8] mac80211: add pre-RCU-sync sta removal driver operation Johannes Berg
2013-12-05 12:35 ` [PATCH 2/8] iwlwifi: mvm: use pre-RCU-sync sta removal operation Johannes Berg
2013-12-05 12:35 ` [PATCH 3/8] mac80211: move 4-addr sta pointer clearing before synchronize_rcu() Johannes Berg
2013-12-05 12:35 ` [PATCH 4/8] mac80211: don't delay station destruction Johannes Berg
2013-12-05 12:35 ` [PATCH 5/8] mac80211: move synchronize_net() before sta key removal Johannes Berg
2013-12-05 12:35 ` [PATCH 6/8] mac80211: optimise synchronize_net() for sta_info_flush Johannes Berg
2013-12-05 12:35 ` [PATCH 7/8] mac80211: optimise mixed AP/VLAN station removal Johannes Berg
2013-12-05 12:35 ` [PATCH 8/8] mac80211: free all AP/VLAN keys at once Johannes Berg
2013-12-05 17:02 ` [PATCH 0/8] mac80211: speed up station cleanup/AP shutdown Christian Lamparter
2013-12-05 17:27 ` Johannes Berg
2013-12-16 10:30 ` Johannes Berg
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=1386195829.7669.3.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=chunkeey@googlemail.com \
--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).