All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Mugunthan V N <mugunthanvnm@ti.com>
Cc: netdev@vger.kernel.org, tglx@linutronix.de,
	"David S. Miller" <davem@davemloft.net>
Subject: [PATCH 3/5 v2] net/cpsw: don't rely only on netif_running() to check which device is active
Date: Mon, 22 Apr 2013 10:30:48 +0200	[thread overview]
Message-ID: <20130422083048.GA8162@linutronix.de> (raw)
In-Reply-To: <51711E0B.4000306@ti.com>

netif_running() reports false before the ->ndo_stop() callback is
called. That means if one executes "ifconfig down" and the system
receives an interrupt before the interrupt source has been disabled we
hang for always for two reasons:
- we never disable the interrupt source because devices claim to be
  already inactive (or non-present) and don't feel responsible.
- since the ISR always reports IRQ_HANDLED the line is never deactivated
  because it looks like the ISR feels responsible.

This patch looks at both, netif_running() and IFF_UP to check if the
device is up. IFF_UP is set after ndo_open() completes and cleared after
ndo_close() completes and netif_running is set before ndo_open() is
called and cleared before ndo_close() completes. Using both will avoid
false positives during the bring down sequence.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
* Mugunthan V N | 2013-04-19 16:05:55 [+0530]:

>The same netif_running(). But why you are telling not to rely on this API?
>device state is updated immediately after successful ndo_open.

I tried to describe the reason for that in my patch description. Here 
it is again: netif_running() reports false before ndo_close() has been
called. That means an interrupt between the flag change and interrupt
disabling in ndo_close() will currently lockup the box (IRQ_NONE would
at least allow the core to disable the interrupt line).

Initialyly I decided against using IFF_UP as well but using would work
without the private active field. So here we have 

-v1…v2: replacing private active field with IFF_UP + netif_running()

How about this?

>Regards
>Mugunthan V N
 drivers/net/ethernet/ti/cpsw.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 3b22a36..2705725 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -511,19 +511,24 @@ static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
 {
 	struct cpsw_priv *priv = dev_id;
 
-	if (likely(netif_running(priv->ndev))) {
+	if (likely(netif_running(priv->ndev) || priv->ndev->flags & IFF_UP)) {
 		cpsw_intr_disable(priv);
 		cpsw_disable_irq(priv);
 		napi_schedule(&priv->napi);
-	} else {
-		priv = cpsw_get_slave_priv(priv, 1);
-		if (likely(priv) && likely(netif_running(priv->ndev))) {
-			cpsw_intr_disable(priv);
-			cpsw_disable_irq(priv);
-			napi_schedule(&priv->napi);
-		}
+		return IRQ_HANDLED;
+	}
+
+	priv = cpsw_get_slave_priv(priv, 1);
+	if (!priv)
+		return IRQ_NONE;
+
+	if (likely(netif_running(priv->ndev) || priv->ndev->flags & IFF_UP)) {
+		cpsw_intr_disable(priv);
+		cpsw_disable_irq(priv);
+		napi_schedule(&priv->napi);
+		return IRQ_HANDLED;
 	}
-	return IRQ_HANDLED;
+	return IRQ_NONE;
 }
 
 static int cpsw_poll(struct napi_struct *napi, int budget)
-- 
1.7.10.4

  reply	other threads:[~2013-04-22  8:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-17 21:52 my small cpsw queue Sebastian Andrzej Siewior
2013-04-17 21:52 ` [PATCH 1/5] net/davinci_cpdma: don't check for jiffies with interrupts Sebastian Andrzej Siewior
2013-04-18 11:49   ` Mugunthan V N
2013-04-17 21:52 ` [PATCH 2/5] net/cpsw: don't continue if we miss to allocate rx skbs Sebastian Andrzej Siewior
2013-04-18 11:50   ` Mugunthan V N
2013-04-18 12:09     ` Sebastian Andrzej Siewior
2013-04-19 10:40       ` Mugunthan V N
2013-04-22  8:05         ` Sebastian Andrzej Siewior
2013-04-17 21:52 ` [PATCH 3/5] net/cpsw: don't rely on netif_running() to check which device is active Sebastian Andrzej Siewior
2013-04-18 11:50   ` Mugunthan V N
2013-04-18 12:10     ` Sebastian Andrzej Siewior
2013-04-19 10:35       ` Mugunthan V N
2013-04-22  8:30         ` Sebastian Andrzej Siewior [this message]
2013-04-22  9:14           ` [PATCH 3/5 v2] net/cpsw: don't rely only " Mugunthan V N
2013-04-22  9:30             ` Sebastian Andrzej Siewior
2013-04-22  9:40               ` Mugunthan V N
2013-04-22  9:49                 ` Sebastian Andrzej Siewior
2013-04-22 10:12                   ` Mugunthan V N
2013-04-22 10:19                     ` Sebastian Andrzej Siewior
2013-04-22 19:21           ` David Miller
2013-04-19 13:10   ` [PATCH 3/5] net/cpsw: don't rely " Sergei Shtylyov
2013-04-22  8:33     ` Sebastian Andrzej Siewior
2013-04-17 21:52 ` [PATCH 4/5] net/davinci_cpdma: remove unused argument in cpdma_chan_submit() Sebastian Andrzej Siewior
2013-04-18 11:51   ` Mugunthan V N
2013-04-17 21:52 ` [PATCH 5/5] net/cpsw: redo rx skb allocation in rx path Sebastian Andrzej Siewior
2013-04-18 11:50   ` Mugunthan V N
2013-04-18 12:13     ` Sebastian Andrzej Siewior
2013-04-19 10:28       ` Mugunthan V N
2013-04-18 14:59     ` Eric Dumazet

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=20130422083048.GA8162@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=mugunthanvnm@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.