Re: [tip:irq/core] genirq: Run irq handlers with interrupts disabled

[Peter Zijlstra <peterz@infradead.org>]

On Tue, 2010-04-13 at 19:33 +0000, tip-bot for Ingo Molnar wrote:
> Commit-ID:  e58aa3d2d0cc01ad8d6f7f640a0670433f794922
> Gitweb:     http://git.kernel.org/tip/e58aa3d2d0cc01ad8d6f7f640a0670433f794922
> Author:     Ingo Molnar <mingo@elte.hu>
> AuthorDate: Fri, 26 Mar 2010 00:06:51 +0000
> Committer:  Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Tue, 13 Apr 2010 16:36:40 +0200
> 
> genirq: Run irq handlers with interrupts disabled
> 
> Running interrupt handlers with interrupts enabled can cause stack
> overflows. That has been observed with multiqueue NICs delivering all
> their interrupts to a single core. We might band aid that somehow by
> checking the interrupt stacks, but the real safe fix is to run the irq
> handlers with interrupts disabled.
> 
> Drivers for whacky hardware still can reenable them in the handler
> itself, if the need arises. (They do already due to lockdep)
> 
> The risk of doing this is rather low:
> 
>  - lockdep already enforces this
>  - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
>  - time keeping is not longer sensitive to the timer interrupt being delayed

Clearly I don't mind this, but shouldn't we at least first convert the
known problematic drivers to an alternative strategy?

IDE-PIO, that one ancient NIC etc..

> ---
>  kernel/irq/handle.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
> index 76d5a67..27e5c69 100644
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -370,9 +370,6 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
>  	irqreturn_t ret, retval = IRQ_NONE;
>  	unsigned int status = 0;
>  
> -	if (!(action->flags & IRQF_DISABLED))
> -		local_irq_enable_in_hardirq();
> -
>  	do {
>  		trace_irq_handler_entry(irq, action);
>  		ret = action->handler(irq, action->dev_id);