linux-kernel - Re: [PATCH 0/7] Boot IRQ quirks and rerouting

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: <1212609577.8410.32.camel@londonpacket.bos.redhat.com>
Date:	Wed, 04 Jun 2008 15:59:37 -0400
From:	Jon Masters <jcm@...hat.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Stefan Assmann <sassmann@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Olaf Dabrunz <od@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting


On Wed, 2008-06-04 at 20:19 +0100, Maciej W. Rozycki wrote:
> On Wed, 4 Jun 2008, Jon Masters wrote:
> 
> > Meanwhile, I think this really shows that a couple of us who've been
> > meaning to poke at per-device IRQs should do so once again. This is the
> > real solution - kill off all those per-IRQ threads, have one per device
> > and split each IRQ into a "top" and "bottom" (just kidding on the names)
> > half. Have the first part be *incredibly* small and just return if the
> > device actually was responsible for the IRQ (and quiesse it), and have
> > the second part do the heavyweight handling. Since the second part can
> > run as a thread (and actually sleep for however long, because it's now
> > per device) - and since we have threaded tasklets and all this on RT
> > anyway - we can just kill off most of the extra logic in many Linux
> > interrupt handlers and have just the interrupt thread do the work. 
> 
>  This is how a lot of our drivers used to work in the old days -- modulo
> implementation details.  It is still a good idea, but it requires more
> care and effort to implement, so people tend to avoid it unless forced by
> the design of hardware involved (cf. phylib in the interrupt mode).

I disagree. I think it's now actually the *inverse*. It /used/ to be
harder, because you didn't have a context in which you could do many
things (so you need to schedule some kind of deferred work), but
actually, it'll become a lot more attractive with device threads.

The only real caveat is for performance critical cases (the reasons we
have special softirqs and the like right now) but there will always be
special cases. Still, I'd like it if writing a Linux interrupt handler
came down to registering two functions - one lightweight tiny one, and
one that's just a thread. Much less room for making mistakes.

Jon.


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