linux-kernel - Re: [PATCH 0/4]: Resolve MSI vs. INTX

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: <Pine.LNX.4.64.0710240046220.32497@iabervon.org>
Date:	Wed, 24 Oct 2007 00:58:45 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	David Miller <davem@...emloft.net>
cc:	linux-kernel@...r.kernel.org, jeff@...zik.org,
	linas@...tin.ibm.com, chunhao.huang@...mail.com, gregkh@...e.de,
	htejun@...il.com, brice.goglin@...il.com,
	david.gaarenstroom@...il.com, linux-pci@...ey.karlin.mff.cuni.cz,
	shane.huang@....com, linux-ide@...r.kernel.org, brice@...i.com,
	mchan@...adcom.com
Subject: Re: [PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks.

On Tue, 23 Oct 2007, David Miller wrote:

> 
> The forthcoming patches are also available from:
> 
> 	kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
> 
> and clean up the handling of the common quirk wherein setting
> INTX_DISABLE will mistakedly disable MSI generation for some
> devices.
> 
> For devices without that problem, we want to keep the pci_intx() calls
> in drivers/pci/msi.c because those help protect against devices
> with the opposite problem.  Such devices always generate INTX
> interrupts even when MSI is enabled, unless INTX_DISABLE is set.
> 
> Michael, please pay special attention to patch #3.  I think I
> picked the correct PCI device IDs to match for the quirk
> (5714* and 5780*) but it's possible we might need more elaborate
> checks here.  It at least worked properly for the chips in my
> Niagara system.

I'm not sure all of the pci_intx() calls in msi.c should be skipped when 
the quirk applies; I think some of them might be there so that the legacy 
interrupt won't be delivered while MSI is turned off (since the handler 
isn't listening for the legacy interrupts). I'd guess this would cause 
people to have their MSI-capable device kill their non-MSI-capable device 
when they restore their laptop (and the shared interrupt fires and gets 
stuck at just the wrong time). No idea if this is a real concern, but I'm 
pretty sure that not all of those calls are recent.

> In addition to the Tigon3 cases, I added quirk entries for the
> SB700/800 SATA chips and the IXP SB400 USB controllers.

There's a couple of ATA drivers that look like they might be trying to 
work around the same bug, but it's a bit hard to tell. It might be good to 
have them use the quirk (or set the flag) because it's cleaner.

	-Daniel
*This .sig left intentionally blank*
-
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/