[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1003251054030.3721@i5.linux-foundation.org>
Date: Thu, 25 Mar 2010 11:01:51 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.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, 25 Mar 2010, Peter Zijlstra wrote:
>
> 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.
The thing is, that won't show the drivers that just simply _expect_
other interrupts to happen.
The SCSI situation, iirc, used to be that certain error conditions simply
caused a delay loop (reset? I forget) that depended on 'jiffies'. So there
was no 'local_irq_enable()' involved, nor did it even happen under any
normal load - only in error situations.
Now, I think (and sincerely) that the SCSI situation is likely long since
fixed, but we have thousands and thousands of drivers, and these kinds of
things are very hard to notice automatically. Are there any cases around
that still have busy-loop delays based on real-time in their irq handlers?
I simply don't know.
Linus
--
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