linux-toradex.git/kernel/irq, branch v2.6.23.12

Fix synchronize_irq races with IRQ handler

2007-12-14T17:50:52+00:00

patch a98ce5c6feead6bfedefabd46cb3d7f5be148d9a in mainline.

Fix synchronize_irq races with IRQ handler

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 
Cc: Chuck Ebbert 
Cc: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

request_irq: fix DEBUG_SHIRQ handling

2007-08-31T08:42:23+00:00

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:44+00:00

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:45+00:00

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:45+00:00

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:16+00:00

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

genirq: temporary fix for level-triggered IRQ resend

2007-08-02T03:46:22+00:00

Marcin Slusarz reported a ne2k-pci "hung network interface" regression.

delayed disable relies on the ability to re-trigger the interrupt in the
case that a real interrupt happens after the software disable was set.
In this case we actually disable the interrupt on the hardware level
_after_ it occurred.

On enable_irq, we need to re-trigger the interrupt. On i386 this relies
on a hardware resend mechanism (send_IPI_self()).

Actually we only need the resend for edge type interrupts. Level type
interrupts come back once enable_irq() re-enables the interrupt line.

I assume that the interrupt in question is level triggered because it is
shared and above the legacy irqs 0-15:

	17:         12   IO-APIC-fasteoi   eth1, eth0

Looking into the IO_APIC code, the resend via send_IPI_self() happens
unconditionally. So the resend is done for level and edge interrupts.
This makes the problem more mysterious.

The code in question lib8390.c does

	disable_irq();
	fiddle_with_the_network_card_hardware()
	enable_irq();

The fiddle_with_the_network_card_hardware() might cause interrupts,
which are cleared in the same code path again,

Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.

So the difference is that we can get a resend on enable_irq, when an
interrupt happens during the time, where we are in the disabled region.

Signed-off-by: Ingo Molnar 
Signed-off-by: Linus Torvalds

rip some includes from linux/interrupt.h

2007-07-29T02:42:22+00:00

Signed-off-by: Al Viro 
Acked-by: Jeff Garzik 
Signed-off-by: Linus Torvalds

x86_64: Report the pending irq if available in smp_affinity

2007-07-22T01:37:07+00:00

Otherwise smp_affinity would only update after the next interrupt
on x86 systems.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

Improve behaviour of spurious IRQ detect

2007-07-16T16:05:46+00:00

Currently we handle spurious IRQ activity based upon seeing a lot of
invalid interrupts, and we clear things back on the base of lots of valid
interrupts.

Unfortunately in some cases you get legitimate invalid interrupts caused by
timing asynchronicity between the PCI bus and the APIC bus when disabling
interrupts and pulling other tricks.  In this case although the spurious
IRQs are not a problem our unhandled counters didn't clear and they act as
a slow running timebomb.  (This is effectively what the serial port/tty
problem that was fixed by clearing counters when registering a handler
showed up)

It's easy enough to add a second parameter - time.  This means that if we
see a regular stream of harmless spurious interrupts which are not harming
processing we don't go off and do something stupid like disable the IRQ
after a month of running.  OTOH lockups and performance killers show up a
lot more than 10/second

[akpm@linux-foundation.org: cleanup]
Signed-off-by: Alan Cox 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds