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]

Message-Id: <200902281202.36804.david-b@pacbell.net>
Date:	Sat, 28 Feb 2009 12:02:36 -0800
From:	David Brownell <david-b@...bell.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	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, a.p.zijlstra@...llo.nl
Subject: Re: lockdep and threaded IRQs (was: ...)

On Saturday 28 February 2009, Thomas Gleixner wrote:
> > > > 
> > > > Where you'll observe twl_init_irq() at line 688 setting
> > > > up the thread and the Primary IRQ Handler (PIH) dispatch.
> > > > That's pretty much bog-standard chained IRQ setup code,
> > > > except that it chains through a thread.
> > > 
> > > So this would be the perfect candidate to test the generic threaded
> > > code I posted a few days ago ?
> > 
> > Could be.  URL?
> 
> http://lkml.org/lkml/2009/2/26/146

Quick report:

 - patch 2/4 didn't apply, mainline uses GFP_ATOMIC in that
   memory allocation not GFP_KERNEL; obvious fix.

 - patch 4/4 also didn't apply, 5/15 hunks failed ... looks
   like IRQ affinity stuff.  free_irq() changes need rework,
   the others look to have obvious fixes.

Got a version that applies to mainline GIT?


At a quick glance it looks like these patches don't cover
set_irq_chained_handler(), which would be trouble since
__setup_irq() doesn't get called in those cases.

They should however handle simpler cases, like I2C devices
that only expose one IRQ instead of needing to demux several
dozen IRQs going to different drivers and subsystems.

And, not touching lockdep, the original ugliness will still
be needed (re-enabling IRQs in threaded handlers).

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