linux-kernel - Re: [PATCH] irq: call also chip->irq_mask from irq

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] [day] [month] [year] [list]

Message-ID: <1316071354.2216.6.camel@sokoban>
Date:	Thu, 15 Sep 2011 10:22:34 +0300
From:	Tero Kristo <t-kristo@...com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	"LKML" <linux-kernel@...r.kernel.org>,
	"Peter Zijlstra" <peterz@...radead.org>
Subject: Re: [PATCH] irq: call also chip->irq_mask from irq_disable

On Wed, 2011-09-14 at 21:50 +0200, Thomas Gleixner wrote:
> On Wed, 14 Sep 2011, Tero Kristo wrote:
> > On Wed, 2011-09-14 at 18:04 +0200, Thomas Gleixner wrote:
> > > What are you trying to solve ?
> > 
> > I was seeing a hang with a chain handler implementation that was caused
> > by this delayed disable implementation, I am using a generic chip with
> > irq_mask / irq_unmask. Adding this patch to the kernel fixed the hang in
> > this case. There might be something wrong in my implementation of the
> > chain handler itself, I'll take a look at it again and try to figure out
> > another way to avoid it. I have another idea I can pursue, and based on
> > some initial testing it actually seems to be working.
> 
> chained handlers are not subject to disable/enable_irq usually. Care
> to share the code ?
> 

Sure, attached my current code as a c-file, it is probable easier to
check it out in this form rather than as a patch. Couple of things to
note in this driver, why I was trying to use irq_disable / irq_enable
was because I want to postpone processing of the wakeup events when we
are waking up from suspend, as this driver is potentially serving
several clients that want to have wakeup events from the IO chain. Now I
just disable all interrupts manually if we are within suspend cycle, and
re-enable all when we have completed wakeup. (Previously I tried calling
irq_disable / irq_enable from suspend.prepare and suspend.complete
callbacks.)

Don't mind about some of the magic numbers in the code, those will be
fixed once I get the proper init sequence in place. Some of the
strangeness in the code is also because this must work for multiple OMAP
versions, thus it should be pretty configurable.

-Tero

Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki

View attachment "omap_prm.c" of type "text/x-csrc" (8323 bytes)