netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
To: Shuyu Wei <wsy2220@gmail.com>, Francois Romieu <romieu@fr.zoreil.com>
Cc: David Miller <davem@davemloft.net>,
	wxt@rock-chips.com, heiko@sntech.de,
	linux-rockchip@lists.infradead.org, netdev@vger.kernel.org,
	al.kochet@gmail.com
Subject: Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer
Date: Sun, 22 May 2016 00:58:55 +0200	[thread overview]
Message-ID: <5740E82F.8040903@gmx.de> (raw)
In-Reply-To: <20160521160910.GA14945@debian-dorm>


On 21.05.2016 18:09, Shuyu Wei wrote:
> Looks like I got it wrong in the first place.
> 
> priv->tx_buff is not for the device, so there's no need to move it.
> The race has been fixed by commit c278c253f3d9, I forgot to check
> it out. That's my fault.
> 
> I do find another problem. We need to use a barrier to make sure
> skb_tx_timestamp() is called before setting the FOR_EMAC flag.
> 

Shuyu,

Could you please test the patch below? I implemented a new approach
in which tx_clean uses txbd_curr to determine if there are more 
descriptors to check or if the loop can be left. 
Memory barriers on both sides (xmit and clean) should ensure that 
SKB and info are only accessed if they are valid.
I also hope that skb_tx_timestamp is not an issue any more.


BTW: concerning get_maintainer Alexander Kochetkov should be CCed for
modifications in this area, so thats what I do hereby.

--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -162,7 +162,13 @@ static void arc_emac_tx_clean(struct net_device *ndev)
 		struct sk_buff *skb = tx_buff->skb;
 		unsigned int info = le32_to_cpu(txbd->info);
 
-		if ((info & FOR_EMAC) || !txbd->data || !skb)
+		if (info & FOR_EMAC)
+			break;
+
+		/* Make sure curr pointer is consistent with info */
+		rmb();
+
+		if (*txbd_dirty == priv->txbd_curr)
 			break;
 
 		if (unlikely(info & (DROP | DEFR | LTCL | UFLO))) {
@@ -195,8 +201,8 @@ static void arc_emac_tx_clean(struct net_device *ndev)
 		*txbd_dirty = (*txbd_dirty + 1) % TX_BD_NUM;
 	}
 
-	/* Ensure that txbd_dirty is visible to tx() before checking
-	 * for queue stopped.
+	/* Ensure that txbd_dirty is visible to tx() and we see the most recent
+	 * value for txbd_curr.
 	 */
 	smp_mb();
 
@@ -680,35 +686,29 @@ static int arc_emac_tx(struct sk_buff *skb, struct net_device *ndev)
 	dma_unmap_len_set(&priv->tx_buff[*txbd_curr], len, len);
 
 	priv->txbd[*txbd_curr].data = cpu_to_le32(addr);
-
-	/* Make sure pointer to data buffer is set */
-	wmb();
+	priv->tx_buff[*txbd_curr].skb = skb;
 
 	skb_tx_timestamp(skb);
 
 	*info = cpu_to_le32(FOR_EMAC | FIRST_OR_LAST_MASK | len);
 
-	/* Make sure info word is set */
+	/* 1. Make sure that with respect to tx_clean everything is set up
+	 * properly before we advance txbd_curr.
+	 * 2. Make sure writes to DMA descriptors are completed before we inform
+	 * the hardware.
+	 */
 	wmb();
 
-	priv->tx_buff[*txbd_curr].skb = skb;
-
 	/* Increment index to point to the next BD */
 	*txbd_curr = (*txbd_curr + 1) % TX_BD_NUM;
 
-	/* Ensure that tx_clean() sees the new txbd_curr before
-	 * checking the queue status. This prevents an unneeded wake
-	 * of the queue in tx_clean().
+	/* Ensure we see the most recent value of txbd_dirty and tx_clean() sees
+	 * the updated value of txbd_curr.
 	 */
 	smp_mb();
 
-	if (!arc_emac_tx_avail(priv)) {
+	if (!arc_emac_tx_avail(priv))
 		netif_stop_queue(ndev);
-		/* Refresh tx_dirty */
-		smp_mb();
-		if (arc_emac_tx_avail(priv))
-			netif_start_queue(ndev);
-	}
 
 	arc_reg_set(priv, R_STATUS, TXPL_MASK);
 
-- 
1.9.1

  parent reply	other threads:[~2016-05-21 22:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 15:25 [PATCH v2] ethernet:arc: Fix racing of TX ring buffer Shuyu Wei
2016-05-17 16:36 ` Aw: " Lino Sanfilippo
2016-05-17 18:24 ` David Miller
     [not found]   ` <20160517.142456.2247845107325931733.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2016-05-18  0:01     ` Francois Romieu
     [not found]       ` <20160518000153.GA21757-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
2016-05-18 20:29         ` Lino Sanfilippo
     [not found]           ` <573CD09D.1060307-Mmb7MZpHnFY@public.gmane.org>
2016-05-18 22:55             ` Francois Romieu
     [not found]               ` <20160518225529.GA18671-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
2016-05-19 21:15                 ` Lino Sanfilippo
     [not found]                   ` <573E2D0C.604-Mmb7MZpHnFY@public.gmane.org>
2016-05-20  0:31                     ` Francois Romieu
2016-05-21 16:09                       ` Shuyu Wei
2016-05-21 19:47                         ` Francois Romieu
     [not found]                           ` <20160521194733.GA30557-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
2016-05-21 23:04                             ` Lino Sanfilippo
     [not found]                               ` <5740E98A.5050803-Mmb7MZpHnFY@public.gmane.org>
2016-05-22 21:21                                 ` Francois Romieu
2016-05-21 22:58                         ` Lino Sanfilippo [this message]
2016-05-22  9:17                           ` Shuyu Wei
2016-05-22 11:30                             ` Lino Sanfilippo
     [not found]                               ` <57419853.9050701-Mmb7MZpHnFY@public.gmane.org>
2016-05-22 22:36                                 ` Francois Romieu
     [not found]                                   ` <20160522223659.GB5086-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
2016-05-24  1:09                                     ` Lino Sanfilippo
     [not found]                                       ` <5743A9DD.8010202-Mmb7MZpHnFY@public.gmane.org>
2016-05-24 19:02                                         ` Francois Romieu
2016-05-24 23:56                                         ` Lino Sanfilippo
2016-05-28  6:43                                           ` Shuyu Wei
2016-05-30 21:41                                             ` Lino Sanfilippo
2016-06-05 14:02                                               ` Shuyu Wei
2016-06-08  7:54                                                 ` Lino Sanfilippo
2016-05-23 11:36                               ` Shuyu Wei
2016-05-24  1:14                                 ` Lino Sanfilippo
2016-05-21 13:46                   ` Shuyu Wei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5740E82F.8040903@gmx.de \
    --to=linosanfilippo@gmx.de \
    --cc=al.kochet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=heiko@sntech.de \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    --cc=wsy2220@gmail.com \
    --cc=wxt@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).