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, 17 Mar 2009 19:00:30 -0700
From:	David Brownell <david-b@...bell.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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, tglx@...utronix.de
Subject: Re: lockdep and threaded IRQs (was: ...)

On Monday 02 March 2009, Ingo Molnar wrote:
> 
> > > Since you care about them - could you please send patches on top 
> > > of the IRQ threading patches to add support for them?
> > 
> > I'll look at that, and try to prepare something on top
> > of the version of the threading patches that gets into
> > the -next tree.  I got the impression there was going
> > to be a v3 of those patches soonish...
> 
> Great! We'll sort out any conflicts so dont worry about that - 
> you can pick up v2 just fine and post patches.

One such patch is about to come, with different $SUBJECT
and trimmed CC list.

Note however that it's completely independent of Thomas'
patches.  It only affects the IRQ dispatch sub-problem;
other bits seem to be needed too.

> If you mean to push the chaining bits into the IRQ thread too, i 
> think the chaining bits actually should never be threaded. Is 
> there a good reason to do that? 

The chaining bits *MUST* be threaded.  The lack of that
support was a key issue with Thomas' patch.  The issue
being that access to the IRQ status registers, as needed
to dispatch the IRQ, is only possible in contexts that
can sleep.  That seems like a good reason.  :)

> It's not like they will really  
> be preemptible (preempting a chaining thread would mean the 
> whole demuxing chain is held up => bad).

See above.  The reason to thread this IRQ handling is
that it can't be done outside of threads ... there's
no other way to access registers via I2C (or SPI, etc).

Accordingly there's no way to avoid preemption ... but
since these IRQs aren't on performance-critical paths,
that's really no bother.

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