All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuyu Wei <wsy2220@gmail.com>
To: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Cc: Francois Romieu <romieu@fr.zoreil.com>,
	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: Mon, 23 May 2016 19:36:09 +0800	[thread overview]
Message-ID: <20160523113609.GA21019@debian-dorm> (raw)
In-Reply-To: <57419853.9050701@gmx.de>

On Sun, May 22, 2016 at 01:30:27PM +0200, Lino Sanfilippo wrote:
> 
> Thanks for testing. However that extra check for skb not being NULL should not be
> necessary if the code were correct. The changes I suggested were all about having
> skb and info consistent with txbd_curr.
> But I just realized that there is still a big flaw in the last changes. While
> tx() looks correct now (we first set up the descriptor and assign the skb and _then_
> advance txbd_curr) tx_clean still is not:
> 
> We _first_ have to read tx_curr and _then_ read the corresponding descriptor and its skb.
> (The last patch implemented just the reverse - and thus wrong - order, first get skb and 
> descriptor and then read tx_curr).
> 
> So the patch below hopefully handles also tx_clean correctly. Could you please do once more a test
> with this one?

Hi Lino, 
This patch worked after a whole night of stress testing.

> > 
> > After further test, my patch to barrier timestamp() didn't work.
> > Just like the original code in the tree, the emac still got stuck under
> > high load, even if I changed the smp_wmb() to dma_wmb(). So the original
> > code do have race somewhere.
> 
> So to make this clear: with the current code in net-next you still see a problem (lockup), right?
Yes, I mean the mainline kernel, which should be the same as net-next.


> > ... and why Francois' fix worked. Please be patient with me :-).
> 
> So which fix(es) exactly work for you and solve your lockup issue?
I mean the patch below, starting this thread.

diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index a3a9392..df3dfef 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -153,9 +153,8 @@ static void arc_emac_tx_clean(struct net_device *ndev)
 {
 	struct arc_emac_priv *priv = netdev_priv(ndev);
 	struct net_device_stats *stats = &ndev->stats;
-	unsigned int i;
 
-	for (i = 0; i < TX_BD_NUM; i++) {
+	while (priv->txbd_dirty != priv->txbd_curr) {
 		unsigned int *txbd_dirty = &priv->txbd_dirty;
 		struct arc_emac_bd *txbd = &priv->txbd[*txbd_dirty];
 		struct buffer_state *tx_buff = &priv->tx_buff[*txbd_dirty];
@@ -685,13 +684,15 @@ static int arc_emac_tx(struct sk_buff *skb, struct net_device *ndev)
 	wmb();
 
 	skb_tx_timestamp(skb);
+	priv->tx_buff[*txbd_curr].skb = skb;
+
+	dma_wmb();
 
 	*info = cpu_to_le32(FOR_EMAC | FIRST_OR_LAST_MASK | len);
 
 	/* Make sure info word is set */
 	wmb();
 
-	priv->tx_buff[*txbd_curr].skb = skb;
 
 	/* Increment index to point to the next BD */
 	*txbd_curr = (*txbd_curr + 1) % TX_BD_NUM;

  parent reply	other threads:[~2016-05-23 11:36 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
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 [this message]
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=20160523113609.GA21019@debian-dorm \
    --to=wsy2220@gmail.com \
    --cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.