Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1257736

[PATCH] Document that IRQ_NONE should be returned when IRQ not actually *handled*

From David Woodhouse <dwmw2@infradead.org>
Newsgroups linux.kernel
Subject [PATCH] Document that IRQ_NONE should be returned when IRQ not actually *handled*
Date 2015-10-28 08:20 +0100
Message-ID <qotbA-7YX-17@gated-at.bofh.it> (permalink)
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

[PATCH] Document that IRQ_NONE should be returned when IRQ not  actually *handled* David Woodhouse <dwmw2@infradead.org> - 2015-10-28 08:20 +0100
  [tip:irq/core]   Document that IRQ_NONE should be returned when IRQ not actually handled tip-bot for David Woodhouse <tipbot@zytor.com> - 2015-10-30 10:20 +0100

csiph-web