* David Brownell [off-list ref] wrote:

On Monday 02 March 2009, Peter Zijlstra wrote:

quoted

On Mon, 2009-03-02 at 14:10 -0800, David Brownell wrote:

quoted

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.

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. It is sometimes used for 
functionality that a subsystem has exported to a lot of drivers 
consciously and which is being removed.

It is never used for a single driver finding a core kernel 
symbol and abusing it in a way that was never intended. Abuse of 
kernel internals by kernel code was never a 'feature'. Just 
because you find a symbol (which is not even exported to 
drivers) does not mean you can use it like that.

If you want to work on genirq threaded IRQ handlers them please 
check out and test the threaded IRQ handlers patches that are 
being worked on at lkml. See:

[patch 0/4] genirq: add infrastructure for threaded interrupt handlers V2

	Ingo