linux-kernel - Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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: <20071217133120.GA11321@elf.ucw.cz>
Date:	Mon, 17 Dec 2007 14:31:20 +0100
From:	Pavel Machek <pavel@....cz>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Paul Rolland <rol@...917.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David P. Reed" <dpreed@...d.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol@...be.net
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

On Mon 2007-12-17 14:22:26, Rene Herman wrote:
> On 17-12-07 14:09, Ingo Molnar wrote:
>
>>>> -#ifndef CONFIG_UDELAY_IO_DELAY
>>>> -static int __init dmi_alternate_io_delay_port(const struct 
>>>> dmi_system_id *id)
>>>> +static int __init dmi_io_delay_0xed_port(const struct dmi_system_id 
>>>> *id)
>>>>  {
>>>> -	printk(KERN_NOTICE "%s: using alternate I/O delay port\n", id->ident);
>>>> -	io_delay = alternate_io_delay;
>>>> +	printk(KERN_NOTICE "%s: using 0xed I/O delay port\n", id->ident);
>>>> +	io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
>>>> +
>>>>  	return 0;
>>>>  }
>>> This isn't correct. DMI shouldn't override the CONFIG choice or someone 
>>> with matching DMI will have a defective CONFIG option. That's why I put 
>>> all of it inside #ifndef.
>> no, the DMI quirk is just that: a quirk that makes boxes work. The DMI 
>> quirk takes precedence over just about any .config default, except an 
>> explicit boot-commandline override.
>
> No, most definitely not. Having the user select udelay or none through the 
> kernel config and then the kernel deciding "ah, you know what, I'll know 
> better and use port access anyway" is _utterly_ broken behaviour. Software 
> needs to listen to its master.

That's what command line is for. Ingo is right here.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/