linux-kernel - Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

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:	Wed, 15 Nov 2006 08:19:05 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Takashi Iwai <tiwai@...e.de>
cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

On Wed, 15 Nov 2006, Takashi Iwai wrote:
> 
> The snd-hda-intel driver has a test of MSI, but it seems not working
> on every machine.  It caused non-cared interrupts and the kernel
> disabled that irq.

Yes. 

Btw, this was why I was claiming that maybe some devices might raise 
_both_ the MSI and the INTx interrupt, which can indeed cause problems 
like that: because we see spurious interrupts on some other irq line (the 
INTx one), we might decide to end up disabling that one, just because we 
can't seem to shut it up.

However, the same kind of schenario may happen if the MSI irq from a 
device simply doesn't _work_ - the device may claim MSI capabilities but 
always uses INTx, and you'd get the same behaviour from just _testing_ the 
MSI line - the irq comes in on the wrong vector, and since you're not 
handling that vector, the kernel has no choice but to say "I will have to 
disable this screaming irq".

So "testing" that an MSI works isn't actually goign to solve any real 
problems. It may or may not show that the MSI works, but regardless of the 
success of the test, it can have deadly consequences for _other_ devices 
if the irq routing (which may be INTx) is broken.

This is why I'm so adamant that we need to _know_ that it works before we 
use it. When irq's get mis-routed, things go downhill real fast. We're 
usually talking "dead machines", and there is very little that a driver 
can do about it.

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