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]
Date:	Sat, 28 Feb 2009 12:10:46 -0800
From:	David Brownell <david-b@...bell.net>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	me@...ipebalbi.com, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	felipe.balbi@...ia.com, dmitry.torokhov@...il.com,
	sameo@...nedhand.com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: lockdep and threaded IRQs

On Saturday 28 February 2009, Stefan Richter wrote:
> David Brownell wrote:
> > The other is that Linux needs real support for threaded
> > interrupts.  Almost every I2C (or SPI) device that raises
> > an IRQ needs its IRQ handler to run in a thread, and most
> > of them have the same type of workqueue-based hack to
> > get such a thread.  (Some others have bugs instead...)
> 
> Since when is having an IRQ handler scheduling a workqueue job a hack?

The only "hack" I recall mentioning was the need to
forcibly re-enable IRQs that lockdep wrongly disabled.


> In kernels whose IRQ handlers don't sleep, we don't pretend that they
> could; instead we defer sleeping work to a context which can sleep.
> 
> Or from another angle:  If a driver requires a kernel with sleeping IRQ
> handlers, why submit it for inclusion into a kernel which does not

(yet)

> provide nonatomic context to IRQ handlers?

Or from yet another angle:  how will progress ever happen
if nobody pushes the boundaries?  :)

We've known for ages that threaded IRQs will eventually
show up in mainline.  Better IMO to plan for that, and
expect minor changes to the drivers which have needed them
all along.

- Dave

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ