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: <20071211163017.GD16750@one.firstfloor.org>
Date:	Tue, 11 Dec 2007 17:30:17 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
Cc:	David Newall <david@...idnewall.com>,
	Rene Herman <rene.herman@...access.nl>,
	Paul Rolland <rol@...917.net>,
	"H. Peter Anvin" <hpa@...or.com>, Krzysztof Halasa <khc@...waw.pl>,
	Pavel Machek <pavel@....cz>, Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David P. Reed" <dpreed@...d.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, rol@...be.net
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

> Most, probably most-all, of the delays to port operations
> on modern ix86 machines are not needed at all. Certainly

We know this. The problem is that there is no good known way to 
figure out which machines need it. Also it is typically 
slow hardware anyways -- the most time critical is probably
the 8259, but nobody who cares about performance still uses 
it except as a fail safe fallback and for those it is better
to be conservative.

> machines that use bridges to expand port I/O to the ISA
> bus do need any such delays. There are exactly two (and

It has been observed to be required talking to some older 
PCI based northbridges too. 

> (2) I/O operations that have two ports, one an index
> port and the other a data port, like the CMOS RTC. Once

and PIT etc.

Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test results with
another port so that we know for sure that the bus aborts 
(and not port 80) is the problem on his box. But it looks like
he doesn't want to do this. Still removing the bus aborts
is probably the correct way to go forward.

Only needs a patch now. If nobody beats me to it i'll
add one later to my tree.

-Andi

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