On Mon, 2016-04-18 at 14:38 +0200, Michal Kazior wrote: > On 18 April 2016 at 07:31, Michal Kazior <michal.kazior@xxxxxxxxx> > wrote: > > > > On 17 April 2016 at 00:29, Johannes Berg <johannes@xxxxxxxxxxxxxxxx > > > wrote: > > > > > > On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote: > > > > > > > > > > > > + struct ieee80211_vif *vif; > > > > + > > > > + /* When packets are enqueued on > > > > txq > > > > it's easy > > > > + * to re-construct the vif > > > > pointer. > > > > There's no > > > > + * more space in tx_info so it > > > > can > > > > be used to > > > > + * store the necessary enqueue > > > > time > > > > for packet > > > > + * sojourn time computation. > > > > + */ > > > > + u64 enqueue_time; > > > > + }; > > > I wonder if we could move something like the hw_key into > > > tx_control > > > instead? > > Hmm.. It's probably doable. From a quick look it'll require quite > > some > > change here and there (e.g. tdls_channel_switch op will need to be > > extended to pass tx_control). I'll play with the idea.. > This is actually far more than I thought initially. Fair enough. Perhaps it could be done for the vif? But ISTR there were issues with that when I looked. We should just get rid of all the rate stuff and convert everything to use rate tables, but ... :) > A lot of drivers > (b43, b43legacy, rtlwifi, wlxxxx, cw1200) access hw_key outside of tx > op context (tx workers, tx completions). I'm not even sure this is > safe (keys can be freed in the meantime by mac80211 hence invaliding > the pointer inside skb, no?). > Hm, yeah, that does seem problematic unless they synchronize against key removal somehow? johannes -- 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
