On Sun, 12 Jan 2020 00:14:55 +0800 Jia-Ju Bai <[email protected]> wrote:
> The functions b43_op_tx() and b43_tx_work() may be concurrently executed. > > In b43_tx_work(), the variable wl->tx_queue_stopped[queue_num] is > accessed with holding a mutex lock wl->mutex. But in b43_op_tx(), the > identical variable wl->tx_queue_stopped[skb->queue_mapping] is accessed > without holding this mutex lock. Thus, a possible data race may occur. > > To fix this data race, in b43_op_tx(), the variable > wl->tx_queue_stopped[skb->queue_mapping] is accessed with holding the > mutex lock wl->mutex. > > This data race is found by the runtime testing of our tool DILP-2. > > Signed-off-by: Jia-Ju Bai <[email protected]> > --- > drivers/net/wireless/broadcom/b43/main.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/b43/main.c > b/drivers/net/wireless/broadcom/b43/main.c > index 39da1a4c30ac..adedb38f50f2 100644 > --- a/drivers/net/wireless/broadcom/b43/main.c > +++ b/drivers/net/wireless/broadcom/b43/main.c > @@ -3625,6 +3625,11 @@ static void b43_op_tx(struct ieee80211_hw *hw, > struct sk_buff *skb) > { > struct b43_wl *wl = hw_to_b43_wl(hw); > + bool stopped; > + > + mutex_lock(&wl->mutex); > + stopped = wl->tx_queue_stopped[skb->queue_mapping]; > + mutex_unlock(&wl->mutex); > > if (unlikely(skb->len < 2 + 2 + 6)) { > /* Too short, this can't be a valid frame. */ > @@ -3634,7 +3639,7 @@ static void b43_op_tx(struct ieee80211_hw *hw, > B43_WARN_ON(skb_shinfo(skb)->nr_frags); > > skb_queue_tail(&wl->tx_queue[skb->queue_mapping], skb); > - if (!wl->tx_queue_stopped[skb->queue_mapping]) { > + if (!stopped) { > ieee80211_queue_work(wl->hw, &wl->tx_work); > } else { > ieee80211_stop_queue(wl->hw, skb->queue_mapping); Hi, thanks for your patch. Unfortunately it is not possible to acquire a sleeping mutex in the tx op: /** * struct ieee80211_ops - callbacks from mac80211 to the driver * * @tx: Handler that 802.11 module calls for each transmitted frame. * skb contains the buffer starting from the IEEE 802.11 header. * The low-level driver should send the frame out based on * configuration in the TX control data. This handler should, * preferably, never fail and stop queues appropriately. * Must be atomic. ^^^^^^^^^^^^^^ I also don't think that the change really fixes any race. The variable tx_queue_stopped is a boolean. Reading that under mutex and then doing the actual action based on a copy does not really change anything. The other end may just set it to false after mutex_unlock, but before the queue_work. Thus this change does probably even increase the race window size. The other thing to consider is: What can actually go wrong, if the race happens? I currently don't see any fatal behavior. A packet might still make it into the queue, although it has already been stopped. But that's not fatal. -- Michael
pgpBtSh99WsrQ.pgp
Description: OpenPGP digital signature
_______________________________________________ b43-dev mailing list [email protected] http://lists.infradead.org/mailman/listinfo/b43-dev
