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: <200903021337.20887.david-b@pacbell.net>
Date:	Mon, 2 Mar 2009 13:37:20 -0800
From:	David Brownell <david-b@...bell.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	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
Subject: Re: lockdep and threaded IRQs (was: ...)

On Monday 02 March 2009, Peter Zijlstra wrote:
> On Mon, 2009-03-02 at 13:04 -0800, David Brownell wrote:
> > On Monday 02 March 2009, Peter Zijlstra wrote:
> > > IRQF_DISABLED is bonkers,
> > 
> > Hmm, after all the work that's been done to get Linux
> > to the point where *most* drivers run without IRQs

Typo:  "drivers run *with* IRQs enabled".  Not "without".
Should be evident from context.

> > enabled ... that sentiment surprises me.
> > 
> > And I suspect it would surprise most driver developers.
> 
> 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.

> > > we should simply always disable interrupts for 
> > > interrupt handlers.
> > 
> > That would be why you have refused to fix the bug
> > in lockdep, whereby it forcibly enables that flag?
> > 
> > I've been wondering for some months now why you've
> > left that bug unfixed.
> 
> Because running irq handlers with irqs enabled it plain silly.

Not if you have hardware-prioritized IRQs, which are
fairly common in some environments ... handling an IRQ
for high priority device A needn't interfere with the
handler for lower priority device B, and the system
overall can work better.

Not if you need to shrink IRQ latencies by minimizing
irqs-off critical sections everywhere ... IRQ handlers
being common offenders for keeping IRQs off too long.

Not when IRQs can be disabled selectively around the
real critical sections ... so drivers can leave IRQs
enabled except in those brief sections.

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