Re: question for mac80211 driver maintainers - RCU usage in drivers

[Christian Lamparter <chunkeey@googlemail.com>]

Hello,

On Wednesday, December 04, 2013 10:30:10 PM Johannes Berg wrote:
> Except for iwlmvm, I don't find much RCU usage wrt. stations in drivers.
carl9170 uses rcu too. (Once there was a nice statistic about rcu
usage by subsystem and drivers, but it somehow disappeared and I
can't find it anymore)

> 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. 
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, ...)?

> Would anyone object if we changed mac80211 to *immediately* free the
> station after calling the driver's sta_state (or sta_remove) callback?
No objection.

> We currently delay this until after an RCU grace period, but that way we
> end up having a lot of delay in station freeing ... We'd like to
> optimise that.
Regards,

Christian

> 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.