linux-kernel - Re: Linux 2.6.20-rc6

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:	Mon, 29 Jan 2007 14:37:23 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: Linux 2.6.20-rc6 - sky2 resume breakage

On Mon, 29 Jan 2007, Thomas Gleixner wrote:
> 
> Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added
> this hackery in the first place, makes the device survive
> suspend/resume.

I suspect some BIOSes do *not* screw up the MSI thing on resume, and 
others do.

I would suggest that the real fix is to not do that kind of hackery at 
suspend/resume time (because we can't know what the heck the BIOS does), 
and instead just do one of two cases:

 - since MSI is known to be broken for the sky2 driver due to firmware 
   bugs, just disable it by default if CONFIG_PM is enabled. The 
   advantages of MSI just aren't all that compelling. Possibly add a 
   command line option to force MSI to be enabled regardless.

   Simple, direct, and should work for everybody.

 - Just add a command line to disable MSI for people that it breaks for. 

   I don't actually like this one. It defaults to the unsafe behaviour, 
   and while that makes sense in a "well, your machine is broken anyway" 
   kind of way, the thing is, the advantages of MSI just aren't big enough 
   to warrant defaulting to a known-unsafe thing, even if only a small 
   percentage of machines are affected.

With _eventually_ maybe having a third possible situation:

 - some way of figuring it out dynamically.

The third case doesn't seem to be very likely in the short term, though, 
which is why I'd suggest one of the first two (the first one being 
probably the best one).

Comments?

		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/