Messages in this thread | | | From | David Brownell <> | Subject | Re: lockdep and threaded IRQs (was: ...) | Date | Mon, 2 Mar 2009 15:48:18 -0800 |
| |
On Monday 02 March 2009, Ingo Molnar wrote: > > > > > What's unfortunate is that you prefer not to fix that > > > > IRQF_DISABLED bug in lockdep, which you co-"maintain". > > > > When running with lockdep, that bug (a) introduces bugs > > > > in some drivers and (b) hides bugs in others. You've > > > > rejected even a minimal warning fix, to help minimize > > > > the amount of time developers waste on (a) and (b). > > > > > > I've come to the conclusion that the only technically sound solution is > > > to do as I proposed today, utterly eliminate !IRQF_DISABLED handlers. > > > > As you announced today. If you truly believe that, then > > you should at least submit a warning patch for 2.6.29-rc > > ("driver X isn't setting IRQF_DISABLED, reimplement!") > > i have changed the BUG_ON() to a WARN_ONCE() message so the > warning is in place now.
The patch Peter sent doesn't relate in the least to removing the IRQF_DISABLED flag though. Patches addressing that would be in setup_irq() code paths not IRQ dispatch.
> > with a Documentation/feature-removal-schedule.txt plan for > > removing that mechanism. [...] > > you are misunderstanding the workings and purpose of > feature-removal-schedule.txt. It is mainly used for > functionality that is user-visible.
If by "user" you include "kernel developers", yes; otherwise, I'd dispute "mainly". The first several entries right now relate to kernel interfaces, as do quite a lot of the others.
> It is sometimes used for > functionality that a subsystem has exported to a lot of drivers > consciously and which is being removed.
The IRQ framework has very consciously exported IRQF_DISABLED. That functionality has been around for a very long time; I'm thinking at least ten years now.
So removing IRQF_DISABLED -- if it's even agreed to be a good idea, which seems to be a minority opinion so far on this thread -- is very much the sort of thing one would expect to appear in that schedule.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |