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]

Message-ID: <alpine.LFD.2.00.0903011043520.29264@localhost.localdomain>
Date:	Sun, 1 Mar 2009 10:44:18 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Christoph Hellwig <hch@...radead.org>
cc:	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, 28 Feb 2009, 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.
> 
> In that model that main loop in handle_IRQ_event would look something
> like this:
> 
> 
> 	do {
> 		ret = action->handler(irq, action->dev_id);
> 		switch (ret) {
> 		case IRQ_HANDLED:
> 			status |= action->flags;
> 			break;
> 		case IRQ_WAKE_THREAD:
> 			if (likely(!test_bit(IRQTF_DIED,
> 					     &action->thread_flags))) {
> 				set_bit(IRQTF_RUNTHREAD, &action->thread_flags);
> 				wake_up_process(action->thread);
> 			}
> 			/*
> 			 * Set it to handled so the spurious check
> 			 * does not trigger.
> 			 */
> 			ret = IRQ_HANDLED;
> 			break;
> 		}
> 		retval |= ret;
> 		action = action->next;
> 	 } while (action);

Makes a lot of sense.

Thanks,

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