linux-kernel - Re: PCI Interrupt

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]

Date:	Wed, 19 Sep 2007 15:13:38 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Frantisek Rysanek <Frantisek.Rysanek@...t.cz>
cc:	linux-kernel@...r.kernel.org
Subject: Re: PCI Interrupt

On Wed, 19 Sep 2007, Frantisek Rysanek wrote:

> On IBM PC compatible hardware, there's always a risky "window of 
> opportunity" that a shared edge-triggered interrupt line gets 
> electrically re-triggered before your ISR manages to service all the 
> devices and ACK the interrupt (I believe RTAI does that in reverse 
> order). In that case, you get a missed interrupt, and your 
> peripherial device may wait for service indefinitely.

 That's because the 8259A does not support truly edge-triggered interrupts 
-- what it supports is a signalling model where the rising edge asserts 
the interrupt and the falling edge negates it if unhandled.  So in some 
sense it is a level-triggered interrupt with no retrigger before the 
falling edge.

> I don't recall if the i8259 AT-pic has some useable "retrigger while 
> in service" register, maybe the APIC does. (I do recall that the 
> 8259's two-register IO footprint is rather convoluted.) I seriously 
> doubt that the presence of such a register would completely eliminate 
> the critical window of time.

 The APIC can support truly edge-triggered interrupts as it only records 
one of the edges (which one of the two it is, depends on the polarity 
setting).  It also records another edge happening between an ACK and an 
EOI and signals another interrupt immediately after the EOI, so nothing is 
lost if pulses are short (assuming there is a reasonably small number of 
sources so that overlapping pulses do not continue for too long).  There 
are subtle differences, as usually with Intel, between APIC 
implementations that may have to be taken into account here.

 Also sharing at the vector level poses interesting issues, but that's 
different matter.

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