Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1535265 > unrolled thread

Avoid deadlock situation due to use of xmit_lock

Back to article view | Back to linux.kernel

Contents

  Avoid deadlock situation due to use of xmit_lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-03 00:10 +0100
    [PATCH 2/2] net: ethernet: stmmac: do not use xmit_lock in tx completion handler Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-03 00:10 +0100
    Re: Avoid deadlock situation due to use of xmit_lock David Miller <davem@davemloft.net> - 2016-12-06 16:10 +0100
      Re: Avoid deadlock situation due to use of xmit_lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-06 20:20 +0100

#1535265 — Avoid deadlock situation due to use of xmit_lock

Hi,

after stumbling over a potential deadlock situation in the altera driver 
(see http://marc.info/?l=linux-netdev&m=148054615230447&w=2), I checked
all other ethernet drivers for the same issue and actually found it in 2
more, namely stmmac, and sxgbe. Please see the commit messages for a 
description of the problem.
These 2 patches fix the concerning drivers.

Regards,
Lino

[toc] | [next] | [standalone]

#1535266 — [PATCH 2/2] net: ethernet: stmmac: do not use xmit_lock in tx completion handler

The driver already uses its private lock for synchronization between the
xmit function and the xmit completion handler, making the additional use of
the xmit_lock unnecessary.
Furthermore the driver does not set NETIF_F_LLTX resulting in xmit to be
called with the xmit_lock held and then taking the private lock.
On the other hand the xmit completion handler uses the reverse locking
order, by first taking the private lock, and then the xmit_lock, which
leads to the potential danger of a deadlock.

Fix this issue by not taking the xmit_lock in the completion handler.
By doing this also remove an unnecessary double check for a stopped tx
queue.

Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

Please note that this patch is only compile tested.

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 48a4e84..8def423 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1380,14 +1380,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
 
 	if (unlikely(netif_queue_stopped(priv->dev) &&
 		     stmmac_tx_avail(priv) > STMMAC_TX_THRESH)) {
-		netif_tx_lock(priv->dev);
-		if (netif_queue_stopped(priv->dev) &&
-		    stmmac_tx_avail(priv) > STMMAC_TX_THRESH) {
-			netif_dbg(priv, tx_done, priv->dev,
-				  "%s: restart transmit\n", __func__);
-			netif_wake_queue(priv->dev);
-		}
-		netif_tx_unlock(priv->dev);
+		netif_dbg(priv, tx_done, priv->dev,
+			  "%s: restart transmit\n", __func__);
+		netif_wake_queue(priv->dev);
 	}
 
 	if ((priv->eee_enabled) && (!priv->tx_path_in_lpi_mode)) {
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1537024

From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sat,  3 Dec 2016 00:06:04 +0100

> after stumbling over a potential deadlock situation in the altera driver 
> (see http://marc.info/?l=linux-netdev&m=148054615230447&w=2), I checked
> all other ethernet drivers for the same issue and actually found it in 2
> more, namely stmmac, and sxgbe. Please see the commit messages for a 
> description of the problem.
> These 2 patches fix the concerning drivers.

First of all, I don't want to apply these patches without proper testing
and ACKs from the individual driver maintainers.

For both of these drivers, this situation only exists because the TX
path uses the unnecessary ->tx_lock.  This private lock should be
removed completely and the driver should use the lock the mid-layer
already holds in the transmit path and take it in the TX reclaim path
instead of the private ->tx_lock.

[toc] | [prev] | [next] | [standalone]

#1537223

Hi,

On 06.12.2016 16:06, David Miller wrote:
> From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> Date: Sat,  3 Dec 2016 00:06:04 +0100
> 
>> after stumbling over a potential deadlock situation in the altera driver 
>> (see http://marc.info/?l=linux-netdev&m=148054615230447&w=2), I checked
>> all other ethernet drivers for the same issue and actually found it in 2
>> more, namely stmmac, and sxgbe. Please see the commit messages for a 
>> description of the problem.
>> These 2 patches fix the concerning drivers.
> 
> First of all, I don't want to apply these patches without proper testing
> and ACKs from the individual driver maintainers.
> 
> For both of these drivers, this situation only exists because the TX
> path uses the unnecessary ->tx_lock.  This private lock should be
> removed completely and the driver should use the lock the mid-layer
> already holds in the transmit path and take it in the TX reclaim path
> instead of the private ->tx_lock.
> 

Ok, I will prepare a new set of patches to remove those private locks entirely.

Regards,
Lino

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web