On Thu, 2017-01-12 at 16:14 +0100, Michal Kazior wrote: > Station pointers are RCU protected so driver must > be extra careful if it tries to store them > internally for later use outside of the RCU > section it obtained it in. > > It was possible for station teardown to race with > some htt events. The possible outcome could be a > use-after-free and a crash. > > Only peer-flow-control capable firmware was > affected (so hardware-wise qca99x0 and qca4019). > > This could be done in sta_state() itself via > explicit synchronize_net() call but there's > already a convenient sta_pre_rcu_remove() op that > can be hooked up to avoid extra rcu stall. I don't think this makes sense. You're not using RCU-protected pointers to the stations yourself, all accesses to them are locked under the &ar->data_lock. As a consequence, you can't have any need for waiting for a grace period. Since you also remove the pointer (under lock) when the station gets removed, I don't think RCU can be the problem? johannes
