linux-kernel - Re: [PATCH] let setup_irq reenable a shared 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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2008 16:11:16 +0200
From:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	<linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] let setup_irq reenable a shared irq

Hello,

Thomas Gleixner wrote:
> On Mon, 28 Apr 2008, Uwe Kleine-König wrote:
> > Consider two devices A and B sharing an irq and B already asserts the irq on
> > a booting machine.
> > If the driver for A is loaded first the irq starts triggering and gets
> > disabled after some time by note_interrupt().  Later when the driver for B
> > is loaded the interrupt should be reenabled---other wise both A and B don't
> > work properly.
> 
> Oh no. There is lots of code in drivers, which does:
> 
>    disable_irq();
>    do_some_protected_stuff();
>    enable_irq();
> 
> So when the second driver is loaded on another CPU it would see the
> IRQ_DISABLED bit set and unconditionally reenable the interrupt. 
> 
> This unprotects the protected operation and definitely triggers the
> WARN_ON() in enable_irq() where we check for desc->depth == 0.
mmpf.

It's not nice to use disable_irq()/enable_irq() in a driver, is it?
 
> I can see the rationale for your patch, as we have no way to silence
> stupid hardware or hardware which was left in that state by the BIOS
> other than disabling the interrupt line completely.
> 
> Waht kind of scenario/devices do you have which trigger this ?
It's a ns9215 SoC.  The rtc component has a clock flag that I need to
set before accessing the address space.  After enabling the clock flag
I get an irq if the rtc is up.  The rtc itself uses the same irq.  As I
want to handle the clk enabling in platform code and the actual rtc in a
driver I need a shared irq.
Now the problem is that the rtc remembers its alarm flags over
reboots[1] and starts asserting the irq when the platform code has
requested the irq.

I currently see two ways to handle that:
 1) find an alternative patch similar to the one I sent that don't break
    driver code; or
 2) let the platform code disable the rtc's irqs.

for 1) you need to remember the reason for disabling the irq (or fix all
drivers not to use disable_irq()).  And 2) is ugly because I have to
ioremap then.

Best regards
Uwe

[1] not entirely sure, but I had the rtc in a state in which the rtc
component asserted an irq directly after a reset.

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
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/