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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
