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]

Date:	Tue, 3 Mar 2009 12:53:02 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	David Brownell <david-b@...bell.net>
cc:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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 Mon, 2 Mar 2009, David Brownell wrote:

> On Monday 02 March 2009, Ingo Molnar wrote:
> > If you want to work on genirq threaded IRQ handlers them please 
> > check out and test the threaded IRQ handlers patches that are 
> > being worked on at lkml. See:
> > 
> > [patch 0/4] genirq: add infrastructure for threaded interrupt handlers V2
> 
> I did check them out, as noted earlier in this thread.
> 
> The significant omission is lack of support for chaining
> such threads.  Example, an I2C device that exposes
> several dozen IRQs with mask/ack/... operations that
> require I2C access.

Well, the significant omission is on your side. Instead of talking to
us about the problems and possible shortcomings of the genirq code you
went there and created your private form of abuse and now you are
complaining about that. The lockdep issue is not caused by lockdep,
it's caused by your using code which is designed to run in hardirq
context from a thread context. It does not become more correct just
because it works fine w/o lockdep.

> I'm not sure what Thomas intends to do with that issue,

I can do something about that, when I know about it, but I have just
learned about the details in the last few days.

> if anything.  It does touch on messy bits of genirq.

Which mess are you referring to ? 

The problem you described is straight forward and as I said before
it's not rocket science to provide support for that in the genirq
code. Your use case does not need to use the chained handler setup at
all, it just needs to request the main IRQ as a simple type and handle
the ack/mask/unmask from the two handler parts.

irqreturn_t hardirq_handler()
{
	ack_mask(irq);
	return IRQ_WAKE_THREAD;
}    

irqreturn_t thread_handler()
{
	pending = read_i2c_pending_irqs();

	while (pending) {
	      ....
	      d->handle_irq(module_irq, d);
	}
	unmask(irq);
}

The only change in the generic code which is needed is a new handler
function for the chained irqs "handle_irq_simple_threaded()" which is
designed to handle the calls from thread context.

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/