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: <20061115112014.54de5b2c@freekitty>
Date:	Wed, 15 Nov 2006 11:20:14 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

On Wed, 15 Nov 2006 11:31:04 +0100
Takashi Iwai <tiwai@...e.de> wrote:

> At Tue, 14 Nov 2006 19:21:17 -0800 (PST),
> David Miller wrote:
> > 
> > From: Linus Torvalds <torvalds@...l.org>
> > Date: Tue, 14 Nov 2006 19:10:42 -0800 (PST)
> > 
> > > Yours was still an example of "nice". And it had absolutely nothing
> > > to do with the _PROBLEM_.
> > 
> > Understood.
> > 
> > BTW, some drivers have taken the approch to add MSI self-tests
> > inside of the driver to ensure correct option of MSI on a given
> > machine.  There's a lot of resistence to that, the reasons for
> > which I grok fully, but I'm not sure other suggestions such as
> > black lists are any better.
> 
> 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.
> 
> > Given current experience maybe white-lists are in fact the way
> > to go.
> 
> Could it be whitelisted in the PCI driver side?  I don't think it's
> good to have a huge white/blacklist in each device driver.
> 

A whitelist is an awkward solution, the problem is the number of
chipsets available with MSI will continue to grow. And the assumption
is that after Microsoft OS supports MSI, that newer chipsets will work.

So by having a whitelist, you force a growing whitelist (in the kernel)
to know about all the possible chipsets.  Since non-whitelisted systems
will end up using INTX and working fine, most users will never try MSI
and the whitelist will end up stale.

A better solution is to have more robust IRQ management that can
deal with misrouted IRQ's and try and recover correctly. How hard would
it be to:
	* remember original IRQ before MSI was enabled
	* make sure all MSI irq's are not flagged SHARED
	* in case of bogus IRQ walk the list and try and correct
	  the problem by reverting to INTX mode.
	* add interface?
		pci_request_irq_msi(pdev, regular_irq_handler, msi_irq_handler, flags, name, context)

All this should be done by the MSI layer, not the device drivers.

-- 
Stephen Hemminger <shemminger@...l.org>
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ