[PATCH 4.2 009/124] amd-xgbe: Fix race between access of desc and desc index

From: Greg Kroah-Hartman
Date: Mon Dec 07 2015 - 11:15:38 EST


4.2-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Lendacky, Thomas" <Thomas.Lendacky@xxxxxxx>

[ Upstream commit 20986ed826cbb36bb8f2d77f872e3c52d8d30647 ]

During Tx cleanup it's still possible for the descriptor data to be
read ahead of the descriptor index. A memory barrier is required between
the read of the descriptor index and the start of the Tx cleanup loop.
This allows a change to a lighter-weight barrier in the Tx transmit
routine just before updating the current descriptor index.

Since the memory barrier does result in extra overhead on arm64, keep
the previous change to not chase the current descriptor value. This
prevents the execution of the barrier for each loop performed.

Suggested-by: Alexander Duyck <alexander.duyck@xxxxxxxxx>
Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -1595,7 +1595,7 @@ static void xgbe_dev_xmit(struct xgbe_ch
packet->rdesc_count, 1);

/* Make sure ownership is written to the descriptor */
- wmb();
+ smp_wmb();

ring->cur = cur_index + 1;
if (!packet->skb->xmit_more ||
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -1816,6 +1816,10 @@ static int xgbe_tx_poll(struct xgbe_chan
return 0;

cur = ring->cur;
+
+ /* Be sure we get ring->cur before accessing descriptor data */
+ smp_rmb();
+
txq = netdev_get_tx_queue(netdev, channel->queue_index);

while ((processed < XGBE_TX_DESC_MAX_PROC) &&


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/