| Message ID | 20170920101123.23312-1-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Johannes Berg |
| Headers | show |
On Wed, 2017-09-20 at 13:11 +0300, Ville Syrjala wrote: > --- a/net/mac80211/tx.c > +++ b/net/mac80211/tx.c > @@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, > struct ieee80211_tx_data tx; > struct sk_buff *skb2; > > - if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP) > + rcu_read_lock(); The documentation says: /** * ieee80211_tx_prepare_skb - prepare an 802.11 skb for transmission * @hw: pointer as obtained from ieee80211_alloc_hw() * @vif: virtual interface * @skb: frame to be sent from within the driver * @band: the band to transmit on * @sta: optional pointer to get the station to send the frame to * * Note: must be called under RCU lock */ You can't even argue that it should be the function itself doing it, because the (admittedly optional) sta pointer would otherwise not have proper protection after you leave the function ... You can't pass out a sta pointer that's RCU protected. Side note: Perhaps some annotation should be there? not sure it's possible - would have to be something like struct ieee80211_sta * __rcu *sta; I guess since the outer pointer isn't protected, only the inner ... Therefore, this patch is wrong. I actually think the same is true for ieee80211_tx_dequeue(), but I'm less sure about it - the sta pointer there clearly is somehow safely passed in (even if it's w/o RCU, the driver can potentially make that safe), but the key pointer seems unsafe in this case (as well) if there's no outer RCU protection. johannes
On Wed, Sep 20, 2017 at 12:39:24PM +0200, Johannes Berg wrote: > On Wed, 2017-09-20 at 13:11 +0300, Ville Syrjala wrote: > > > --- a/net/mac80211/tx.c > > +++ b/net/mac80211/tx.c > > @@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, > > struct ieee80211_tx_data tx; > > struct sk_buff *skb2; > > > > - if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP) > > + rcu_read_lock(); > > The documentation says: > > /** > * ieee80211_tx_prepare_skb - prepare an 802.11 skb for transmission > * @hw: pointer as obtained from ieee80211_alloc_hw() > * @vif: virtual interface > * @skb: frame to be sent from within the driver > * @band: the band to transmit on > * @sta: optional pointer to get the station to send the frame to > * > * Note: must be called under RCU lock > */ > > You can't even argue that it should be the function itself doing it, > because the (admittedly optional) sta pointer would otherwise not have > proper protection after you leave the function ... You can't pass out a > sta pointer that's RCU protected. Yeah, I suppose that would need rcu_handoff+some other mechanism to make sure it stays around after that. > > Side note: Perhaps some annotation should be there? not sure it's > possible - would have to be something like > struct ieee80211_sta * __rcu *sta; > > I guess since the outer pointer isn't protected, only the inner ... I think just the fact that even the pointers in ieee80211_tx_data don't have the __rcu annotation makes it rather hard to see what is really rcu protected and what isn't. If every user of those pointers would have to do the rcu_dereference() things would be rather more explicit. > Therefore, this patch is wrong. OK, so the problem is in ath9k then. > I actually think the same is true for ieee80211_tx_dequeue(), but I'm > less sure about it - the sta pointer there clearly is somehow safely > passed in (even if it's w/o RCU, the driver can potentially make that > safe), but the key pointer seems unsafe in this case (as well) if > there's no outer RCU protection. Well, I think this is as far as I want to dig into the matter. I can respin the patch once more with just tx_dequeue() fix in there, if you want (not sure you do if you think it's wrong as well). After that I'll leave it to someone who actually knows what they're doing with mac80211 ;)
On Wed, 2017-09-20 at 15:11 +0300, Ville Syrjälä wrote: > > > I guess since the outer pointer isn't protected, only the inner ... > > I think just the fact that even the pointers in ieee80211_tx_data > don't have the __rcu annotation makes it rather hard to see what is > really rcu protected and what isn't. If every user of those pointers > would have to do the rcu_dereference() things would be rather more > explicit. It wouldn't make sense though, because those users don't need to provide the protection, and they don't need to make sure to use the pointer in an RCU safe manner (access once etc.) since they're in code that can't really go wrong... mostly. > > Therefore, this patch is wrong. > > OK, so the problem is in ath9k then. I agree. > > I actually think the same is true for ieee80211_tx_dequeue(), but [...] > Well, I think this is as far as I want to dig into the matter. I can > respin the patch once more with just tx_dequeue() fix in there, if > you want (not sure you do if you think it's wrong as well). After > that I'll leave it to someone who actually knows what they're doing > with mac80211 ;) :-) I think we should rather document that RCU is required for that function, I think for some usages it may be OK without but with keys I'm pretty sure you'll need it. johannes
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 94826680cf2b..fc4d8294d664 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, struct ieee80211_tx_data tx; struct sk_buff *skb2; - if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP) + rcu_read_lock(); + + if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP) { + rcu_read_unlock(); return false; + } info->band = band; info->control.vif = vif; info->hw_queue = vif->hw_queue[skb_get_queue_mapping(skb)]; - if (invoke_tx_handlers(&tx)) + if (invoke_tx_handlers(&tx)) { + rcu_read_unlock(); return false; + } if (sta) { if (tx.sta) @@ -1792,9 +1798,12 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, if (WARN_ON(skb2 != skb || !skb_queue_empty(&tx.skbs))) { ieee80211_free_txskb(hw, skb2); ieee80211_purge_tx_queue(hw, &tx.skbs); + rcu_read_unlock(); return false; } + rcu_read_unlock(); + return true; } EXPORT_SYMBOL(ieee80211_tx_prepare_skb); @@ -3413,6 +3422,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, spin_lock_bh(&fq->lock); + rcu_read_lock(); + if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags)) goto out; @@ -3511,6 +3522,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, IEEE80211_SKB_CB(skb)->control.vif = vif; out: + rcu_read_unlock(); + spin_unlock_bh(&fq->lock); return skb;