Prev: sched: add bandwidth management for sched_dl.
Next: [tip:perf/core] perf probe: Fix to use correct debugfs path finder
From: Peter Zijlstra on 15 Apr 2010 03:40 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(a)elte.hu> > AuthorDate: Fri, 26 Mar 2010 00:06:51 +0000 > Committer: Thomas Gleixner <tglx(a)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); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |