[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1269539254.12097.100.camel@laptop>
Date: Thu, 25 Mar 2010 18:47:34 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
LKML <linux-kernel@...r.kernel.org>, jesse.brandeburg@...el.com
Subject: Re: [PATCH] Prevent nested interrupts when the IRQ stack is near
overflowing v2
On Thu, 2010-03-25 at 09:13 -0700, Linus Torvalds wrote:
> But see above. This is _not_ something that a driver can do any more. They
> don't know whether the interrupt might end up being shared. Just blindly
> setting IRAF_DISABLED in a driver is _not_ the answer. But being smarter
> in the generic irq handler code might work.
>
> And then, what we could do, is to mark the drivers that absolutely _must_
> be able to nest specially. Like the IDE driver when in PIO mode. Or maybe
> the SCSI drivers, if they still depend on that timer interrupt happening
> while they are busy.
FWIW lockdep forces IRQF_DISABLED and yells when anybody does
local_irq_enable() while in hardirq context, I haven't seen any such
splats in a long while, except from the ARM people who did funny things
with building their own threaded interrupts or somesuch.
So I'm sure there's some devices, like IDE PIO and the curious 8390, and
maybe some other drivers that aren't as common, but I don't think the
situation is quite as bad as some people paint it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists