linux-kernel - Re: lockdep and threaded IRQs (was: ...)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090302232650.GA14515@elte.hu>
Date:	Tue, 3 Mar 2009 00:26:50 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Brownell <david-b@...bell.net>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>, me@...ipebalbi.com,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	felipe.balbi@...ia.com, dmitry.torokhov@...il.com,
	sameo@...nedhand.com, tglx@...utronix.de
Subject: Re: lockdep and threaded IRQs (was: ...)

* David Brownell <david-b@...bell.net> wrote:

> On Monday 02 March 2009, Peter Zijlstra wrote:
> > On Mon, 2009-03-02 at 14:10 -0800, David Brownell 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.

> 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
--
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/