From: David Woodhouse <dwmw2@infradead.org>
To: linux-kernel@vger.kernel.org, tglx@linutronix.de, davem@davemloft.net
Subject: [PATCH] Document that IRQ_NONE should be returned when IRQ not actually *handled*
Date: Wed, 28 Oct 2015 16:14:31 +0900 [thread overview]
Message-ID: <1446016471.3405.201.camel@infradead.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
Our IRQ storm detection works when an interrupt handler returns
IRQ_NONE for thousands of consecutive interrupts in a second. It
doesn't hurt to occasionally return IRQ_NONE when the interrupt is
actually genuine.
Drivers should only be returning IRQ_HANDLED if they have actually
*done* something to stop an interrupt from happening — it doesn't just
mean "this really *was* my device".
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
See recent discussion about the 8139cp Ethernet driver¹. It developed
(OK, I introduced) a bug where it would re-enable the RX IRQ when
handling a TX timeout and resetting the hardware.
This leads to an IRQ storm with cp_interrupt() *not* doing anything
about the RX IRQ, because NAPI was already scheduled. And then
returning IRQ_HANDLED anyway. And complete death of the machine.
Our IRQ storm detection should handle that kind of thing — it's
designed to catch both hardware *and* software screwups. But because of
the cp_interrupt() return value, it didn't.
I tried to fix cp_interrupt(), and submitted a patch which made the
failure mode much saner — the offending IRQ got disabled and the
machine continued happily, with the network even *working* in polling
mode. It met with resistance.
To overcome that resistance, we should clearly document the expectation
that device drivers should return IRQ_NONE in that kind of case. Let's
start by at least fixing the *wrong* text in irqreturn.h, which says
that IRQ_NONE means "not my device"...
¹ http://www.spinics.net/lists/netdev/msg343991.html
http://www.spinics.net/lists/netdev/msg343995.html
http://www.spinics.net/lists/netdev/msg344265.html
diff --git a/include/linux/irqreturn.h b/include/linux/irqreturn.h
index e374e36..eb1bdcf 100644
--- a/include/linux/irqreturn.h
+++ b/include/linux/irqreturn.h
@@ -3,7 +3,7 @@
/**
* enum irqreturn
- * @IRQ_NONE interrupt was not from this device
+ * @IRQ_NONE interrupt was not from this device or was not handled
* @IRQ_HANDLED interrupt was handled by this device
* @IRQ_WAKE_THREAD handler requests to wake the handler thread
*/
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
next reply other threads:[~2015-10-28 7:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 7:14 David Woodhouse [this message]
2015-10-30 9:18 ` [tip:irq/core] Document that IRQ_NONE should be returned when IRQ not actually handled tip-bot for David Woodhouse
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=1446016471.3405.201.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox