[PATCH net] bnxt_en: Fix potential race condition in bnxt_tx_enable()

txr->dev_state is always manipulated after acquiring the transmit queue
lock, except in bnxt_tx_enable(), which seems suspicious here, so also
acquire the transmit queue lock before changing the value.

Reported-by: coverity (CID 1339583)
Fixes: c0c050c58d840 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index c777cde85ce4..904c2a8ece12 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c

@@ -4599,7 +4599,9 @@ static void bnxt_tx_enable(struct bnxt *bp)
 	for (i = 0; i < bp->tx_nr_rings; i++) {
 		txr = &bp->tx_ring[i];
 		txq = netdev_get_tx_queue(bp->dev, i);
+		__netif_tx_lock(txq, smp_processor_id());
 		txr->dev_state = 0;
+		__netif_tx_unlock(txq);
 	}
 	netif_tx_wake_all_queues(bp->dev);
 	if (bp->link_info.link_up)

-- 
2.7.4

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Jul 2016 16:42:01 -0700

You're going to have to explain how this could possibly cause a
problem, because I'm pretty sure it can't.

Either the reader sees 0, or non-zero, in this value.

And adding locking around this assignment does not change that at all.

On Fri, Jul 15, 2016 at 11:20 PM, David Miller [off-list ref] wrote:

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Jul 2016 16:42:01 -0700

quoted

@@ -4599,7 +4599,9 @@ static void bnxt_tx_enable(struct bnxt *bp)
      for (i = 0; i < bp->tx_nr_rings; i++) {
              txr = &bp->tx_ring[i];
              txq = netdev_get_tx_queue(bp->dev, i);
+             __netif_tx_lock(txq, smp_processor_id());
              txr->dev_state = 0;
+             __netif_tx_unlock(txq);

You're going to have to explain how this could possibly cause a
problem, because I'm pretty sure it can't.

Either the reader sees 0, or non-zero, in this value.

And adding locking around this assignment does not change that at all.

Florian, I agree with David.  The lock is not needed.  The lock in
bnxt_tx_disable() is also unnecessary and should be removed.  Thanks.

txr->dev_state was not consistently manipulated with the acquisition of
the per-queue lock, after further inspection the lock does not seem
necessary, either the value is read as BNXT_DEV_STATE_CLOSING or 0.

Reported-by: coverity (CID 1339583)
Fixes: c0c050c58d840 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:

- remove locking in bnxt_tx_disable() as recommended by Michael

 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index c777cde85ce4..15e1d1885919 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c

@@ -4580,9 +4580,7 @@ static void bnxt_tx_disable(struct bnxt *bp)
 		for (i = 0; i < bp->tx_nr_rings; i++) {
 			txr = &bp->tx_ring[i];
 			txq = netdev_get_tx_queue(bp->dev, i);
-			__netif_tx_lock(txq, smp_processor_id());
 			txr->dev_state = BNXT_DEV_STATE_CLOSING;
-			__netif_tx_unlock(txq);
 		}
 	}
 	/* Stop all TX queues */

-- 
2.7.4

On Mon, Jul 18, 2016 at 1:02 PM, Florian Fainelli [off-list ref] wrote:

txr->dev_state was not consistently manipulated with the acquisition of
the per-queue lock, after further inspection the lock does not seem
necessary, either the value is read as BNXT_DEV_STATE_CLOSING or 0.

Reported-by: coverity (CID 1339583)
Fixes: c0c050c58d840 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks Florian.

Acked-by: Michael Chan <michael.chan@broadcom.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 18 Jul 2016 13:02:47 -0700

txr->dev_state was not consistently manipulated with the acquisition of
the per-queue lock, after further inspection the lock does not seem
necessary, either the value is read as BNXT_DEV_STATE_CLOSING or 0.

Reported-by: coverity (CID 1339583)
Fixes: c0c050c58d840 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:

- remove locking in bnxt_tx_disable() as recommended by Michael

Applied to net-next, thanks.