On Mon, 2009-03-02 at 14:09 -0800, David Brownell wrote: > On Monday 02 March 2009, Peter Zijlstra wrote: > > > > How so?, its the natural extension of that work. > > > > > > Not the work to shrink the amount of time IRQ latencies > > > by shrinking the amount of time IRQs are disabled by > > > IRQ handlers. > > > > Ugh, that's done by pushing work out of the hardirq context, > > That's one of many techniques currently used. > > Tradeoffs don't always favor larger driver updates > and re-validation though. Sometimes it's simpler > to just leverage the reality that "hardirq context" > does not require using IRQF_DISABLED. Simpler doesn't mean its a good idea, it opens the door to stack overruns for one. Its very unfortunate that people think its a good idea. > > not by doing silly things like enabling irqs from hardirq context. > > Somehow I'm certain you have NOT analysed every one of the > thousands of IRQ handlers in various Linux drivers to know > with certainty that's not the reason IRQ_DISABLED is cleared. > > There are also *other* reasons to leave IRQ_DISABLED clear. There might be reasons to do so, that doesn't mean its a good idea and the desired thing to do. I state that every !IRQF_DISABLED usage is a bug, either due to broken hardware or broken drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
