Subject: Re: [PATCH 2/2] net: ethernet: stmmac: remove private tx queue lock

From: Pavel Machek <[email-masked]>
Date: Thu, 8 Dec 2016 16:46:11 +0100

On Thu 2016-12-08 10:26:41, David Miller wrote:
> From: Pavel Machek <[email-masked]>
> Date: Thu, 8 Dec 2016 15:08:46 +0100
> 
> > On Wed 2016-12-07 18:41:11, David Miller wrote:
> >> From: Pavel Machek <[email-masked]>
> >> Date: Wed, 7 Dec 2016 22:37:57 +0100
> >> 
> >> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > index 982c952..7415bc2 100644
> >> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > @@ -1308,7 +1308,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> >> >  	unsigned int bytes_compl = 0, pkts_compl = 0;
> >> >  	unsigned int entry = priv->dirty_tx;
> >> >  
> >> > -	spin_lock(&priv->tx_lock);
> >> > +	netif_tx_lock_bh(priv->dev);
> >> >  
> >> >  	priv->xstats.tx_clean++;
> >> >  
> >> 
> >> stmmac_tx_clean() runs from either the timer or the NAPI poll handler,
> >> both execute from software interrupts, therefore _bh() should be
> >> unnecessary.
> > 
> > I've tried the test again with netif_tx_lock() (not _bh()) and it
> > survived for more then four hours. Strange...
> 
> It's not strange, it's completely expected.

Well, I tried that exact test before, and it survived for something
like 10 minutes. So yes... this surprised me.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html