linux/kernel/irq, branch v2.6.24

genirq: revert lazy irq disable for simple irqs

2007-12-18T17:05:58Z

In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling was implemented, and the simple irq handler had a masking set to it. Remy Bohmer discovered that some devices in the ARM architecture would trigger the mask, but never unmask it. His patch to do the unmasking was questioned by Russell King about masking simple irqs to begin with. Looking further, it was discovered that the problems Remy was seeing was due to improper use of the simple handler by devices, and he later submitted patches to fix those. But the issue that was uncovered was that the simple handler should never mask. This patch reverts the masking in the simple handler. Signed-off-by: Steven Rostedt Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Acked-by: Russell King

__do_IRQ does not check IRQ_DISABLED when IRQ_PER_CPU is set

2007-11-15T02:45:43Z

In __do_IRQ(), the normal case is that IRQ_DISABLED is checked and if set the handler (handle_IRQ_event()) is not called. Earlier in __do_IRQ(), if IRQ_PER_CPU is set the code does not check IRQ_DISABLED and calls the handler even though IRQ_DISABLED is set. This behavior seems unintentional. One user encountering this behavior is the CPE handler (in arch/ia64/kernel/mca.c). When the CPE handler encounters too many CPEs (such as a solid single bit error), it sets up a polling timer and disables the CPE interrupt (to avoid excessive overhead logging the stream of single bit errors). disable_irq_nosync() is called which sets IRQ_DISABLED. The IRQ_PER_CPU flag was previously set (in ia64_mca_late_init()). The net result is the CPE handler gets called even though it is marked disabled. If the behavior of not checking IRQ_DISABLED when IRQ_PER_CPU is set is intentional, it would be worthy of a comment describing the intended behavior. disable_irq_nosync() does call chip->disable() to provide a chipset specifiec interface for disabling the interrupt, which avoids this issue when used. Signed-off-by: Russ Anderson Cc: "Luck, Tony" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Bjorn Helgaas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix synchronize_irq races with IRQ handler

2007-10-23T16:01:31Z

As it is some callers of synchronize_irq rely on memory barriers to provide synchronisation against the IRQ handlers. For example, the tg3 driver does tp->irq_sync = 1; smp_mb(); synchronize_irq(); and then in the IRQ handler: if (!tp->irq_sync) netif_rx_schedule(dev, &tp->napi); Unfortunately memory barriers only work well when they come in pairs. Because we don't actually have memory barriers on the IRQ path, the memory barrier before the synchronize_irq() doesn't actually protect us. In particular, synchronize_irq() may return followed by the result of netif_rx_schedule being made visible. This patch (mostly written by Linus) fixes this by using spin locks instead of memory barries on the synchronize_irq() path. Signed-off-by: Herbert Xu Acked-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds

Compile handle_percpu_irq even for uniprocessor kernels

2007-10-17T15:43:00Z

Compiling handle_percpu_irq only on uniprocessor generates an artificial special case so a typical use like: set_irq_chip_and_handler(irq, &some_irq_type, handle_percpu_irq); needs to be conditionally compiled only on SMP systems as well and an alternative UP construct is usually needed - for no good reason. This fixes uniprocessor configurations for some MIPS SMP systems. Signed-off-by: Ralf Baechle Acked-by: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix CONFIG_DEBUG_SHIRQ trigger on free_irq()

2007-10-17T15:42:49Z

Andy Gospodarek pointed out that because we return in the middle of the free_irq() function, we never actually do call the IRQ handler that just got deregistered. This should fix it, although I expect Andrew will want to convert those 'return's to 'break'. That's a separate change though. Signed-off-by: David Woodhouse Cc: Andy Gospodarek Cc: Fernando Luis Vzquez Cao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

request_irq: fix DEBUG_SHIRQ handling

2007-08-31T08:42:23Z

Mariusz Kozlowski reported lockdep's warning: > ================================= > [ INFO: inconsistent lock state ] > 2.6.23-rc2-mm1 #7 > --------------------------------- > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&tp->lock){+...}, at: [] rtl8139_interrupt+0x27/0x46b [8139too] > {in-hardirq-W} state was registered at: > [] __lock_acquire+0x949/0x11ac > [] lock_acquire+0x99/0xb2 > [] _spin_lock+0x35/0x42 > [] rtl8139_interrupt+0x27/0x46b [8139too] > [] handle_IRQ_event+0x28/0x59 > [] handle_level_irq+0xad/0x10b > [] do_IRQ+0x93/0xd0 > [] common_interrupt+0x2e/0x34 ... > other info that might help us debug this: > 1 lock held by ifconfig/5492: > #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x1c/0x1f > > stack backtrace: ... > [] _spin_lock+0x35/0x42 > [] rtl8139_interrupt+0x27/0x46b [8139too] > [] free_irq+0x11b/0x146 > [] rtl8139_close+0x8a/0x14a [8139too] > [] dev_close+0x57/0x74 ... This shows that a driver's irq handler was running both in hard interrupt and process contexts with irqs enabled. The latter was done during free_irq() call and was possible only with CONFIG_DEBUG_SHIRQ enabled. This was fixed by another patch. But similar problem is possible with request_irq(): any locks taken from irq handler could be vulnerable - especially with soft interrupts. This patch fixes it by disabling local interrupts during handler's run. (It seems, disabling softirqs should be enough, but it needs more checking on possible races or other special cases). Reported-by: Mariusz Kozlowski Signed-off-by: Jarek Poplawski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

free_irq(): fix DEBUG_SHIRQ handling

2007-08-23T02:52:44Z

If we're going to run the handler from free_irq() then we must do it with local irq's disabled. Otherwise lockdep complains that the handler is taking irq-safe spinlocks in a non-irq-safe fashion. Cc: Ingo Molnar Cc: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

genirq: suppress resend of level interrupts

2007-08-12T18:05:45Z

Level type interrupts are resent by the interrupt hardware when they are still active at irq_enable(). Suppress the resend mechanism for interrupts marked as level. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds

genirq: cleanup mismerge artifact

2007-08-12T18:05:45Z

Commit 5a43a066b11ac2fe84cf67307f20b83bea390f83: "genirq: Allow fasteoi handler to retrigger disabled interrupts" was erroneously applied to handle_level_irq(). This added the irq retrigger / resend functionality to the level irq handler. Revert the offending bits. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds

Revert "genirq: temporary fix for level-triggered IRQ resend"

2007-08-09T15:10:16Z

This reverts commit 0fc4969b866671dfe39b1a9119d0fdc7ea0f63e5. It was always meant to be temporary, but it's generating more useless noise than anything else, and we probably should never have done it in the generic kernel (only had the people involved test it on their own). Signed-off-by: Linus Torvalds