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]

Date:	Tue, 1 Jan 2008 17:43:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"David P. Reed" <dpreed@...d.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rene Herman <rene.herman@...il.com>,
	Paul Rolland <rol@...917.net>, Pavel Machek <pavel@....cz>,
	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.

* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> Ingo - the fact that so many ISA bus devices need _p to mean "ISA bus 
> clocks" says to me we should keep the _p port 0x80 using variant for 
> old systems/device combinations (eg ISA ethernet cards) which won't 
> show up in any problem system (we know this from 15 odd years of 
> testing), but stop using it for PCI and embedded devices on modern 
> systems.

yes, ISA is fragile, and no way do we want to remove the delay, but are 
there strong counter-arguments against doing the clean thing and adding 
an udelay(2) (or udelay(1)) to replace those _p() uses in ISA drivers? 
That removes the global effect once and forever. Initially for 
standalone drivers without early bootup functionality, not platform 
drivers that might need to run before we have calibrated udelay.

if someone runs a fresh new kernel on an ancient device then timings 
_will_ change a bit, no matter what we do. Alignments change, the 
compiler output will change (old compilers get deprecated so a new 
compiler might have to be picked), cache effects change - and this is 
inevitable. The important thing is to not eliminate the delays - but we 
sure dont have to keep them cycle accurate (we couldnt even if we wanted 
to). The only way to get the _exact same_ behavior is to not change the 
kernel at all.

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