linux-kernel - Re: Bugfixes: PCI devices get assigned redundant IRQs

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: <op.tmvewmxdb742fu@pc-andreas>
Date:	Sun, 28 Jan 2007 16:35:06 +0100 (MET)
From:	"Andreas Block" <job@...reasblock.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Xavier Bestel" <xavier.bestel@...e.fr>,
	linux-kernel@...r.kernel.org,
	"Andreas Block" <andreas.block@...-electronics.com>
Subject: Re: Bugfixes: PCI devices get assigned redundant IRQs

Am Sun, 28 Jan 2007 09:04:41 +0100 schrieb H. Peter Anvin <hpa@...or.com>:

> I think you're confusing the Interrupt Line register and the Interrupt  
> Pin register.  The Interrupt Line register is platform-dependent, but on  
> x86 platforms it generally contains the IRQ number (and IRQ 0 is valid,  
> although in practice it is never used since IRQ 0 is the system timer  
> and is never connected to the PCI bus), or 255 meaning "none" -- see the  
> footnote on page 223 of the PCI 3.0 spec.

No, I don't think so. I meant the PCI Interrupt Pin register and not the  
Interrupt line register. I do know, that the latter contains a platform  
dependent interrupt assignment. In the former a device states which  
interrupt "trace" the device is connected to (Int A-D).
Perhaps you take at look at the code, I think, it's dealing with the  
register I described (Interrupt pin).

Linus stated his opinion about the patch and thinks, it should be well  
tested in -mm kernel, because it might break devices, which do not comply  
to the PCI spec.
I second that. If there're indeed devices out there, which violate the  
spec in this point, the patch would hurt more, than it's doing any good.
As I wrote in my first message, the consequences of this rather small bug  
(if it is one and not a workaround for bad devices) are harmless.

Regards,
Andreas
-
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/