linux-kernel - Re: [patch 3/4] genirq: add a quick check handler

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:	Thu, 05 Mar 2009 11:59:09 -0800
From:	Sven-Thorsten Dietrich <sdietrich@...ell.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arjan van de Veen <arjan@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: [patch 3/4] genirq: add a quick check handler

On Sat, 2009-02-28 at 17:24 -0500, Christoph Hellwig wrote:
> I really disagree with the notation of the pre-handler.  Instead of
> adding an additional pre handler method you should add a new threadfn
> method.  The handler could just as now handle/not handle the interrupt,
> or as a third option defer it to the thread.  That makes the different
> semantics a lot clearer, and means ->handler and ->threadfn both have
> very well defined contexts, instead of sometimes calling ->handler
> sometimes from irq and sometimes from thread context.  This also
> makes it much easier for complex hardware that might have simple and
> fast interrupts that it may want to handle directly from hardirq context
> in just a couple of cycles or complex interrupts that might be deferred
> to process context.
> 

Most of the IRQ handler, whether run in a thread or IRQ context, will be
the same code - so what you are proposing would have to eliminate code
duplication as well as heavy runtime branching overhead.

Ultimately, no matter how its done, the concept of disabling IRQ assert
at the device level, rather than the apic level, is the optimal
"correct" implementation.

Formulating that into the code, as Thomas proposed with the quickcheck,
supplies structural demarcation for semi as well as software design.

Things just get quite ugly - as-is- when you try to add runtime thread
enable and disable.

Sven


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