linux-kernel - Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ handlers

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: <4560C1C6.8000203@ru.mvista.com>
Date:	Sun, 19 Nov 2006 23:42:46 +0300
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Ingo Molnar <mingo@...e.hu>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org, dwalker@...sta.com
Subject: Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi
 type IRQ handlers

Hello.

Benjamin Herrenschmidt wrote:

>>   The fasteoi flow seem to only had been used for x86 IOAPIC in the RT patch 
>>only *before* PPC took to using them in the mainline...

> I don't think so, I asked for the fasteoi to be created while porting
> ppc to genirq :-)

    Oh, I was unaware of such details. :-)

>>>threaded handlers need a mask() + an ack(), because that's the correct

>>    Not all of them. This could be customized on type-by-type basis. I.e. we 
>>could call eoi() instead of ack() for fasteoi chips without having to resort 
>>to the duplicated ack/eoi handlers.

> I still don't see how ack() makes sense in the context of a fasteoi...

    It doesn't make sense even in the context of 8259 with its level/edge 
flows. That's what I'm talking about...

> You can either just not EOI until it's handled, but you'll indeed
> introduce delays for other interrupts of the same priority or lower, or
> you can mask() and then eoi(), which is, I think, what Apple does, to
> deliver the interrupt to a thread (and later unmask).
> In any case, I don't see the need for a separate ack().

   Yeah, that's what the threaded versions of flow handlers are doing. Except 
they're calling ack() to actually EOI an IRQ.

> Ben.

WBR, Sergei
-
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/