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:	Fri, 18 Jan 2008 19:12:02 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Jesse Barnes <jesse.barnes@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	ebiederm@...ssion.com, rdreier@...co.com,
	torvalds@...ux-foundation.org, gregkh@...e.de, airlied@...net.ie,
	davej@...hat.com, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

On Fri, Jan 18, 2008 at 08:46:02AM -0800, Jesse Barnes wrote:
> On Friday, January 18, 2008 5:12 am Andi Kleen wrote:
> > > (AMD machines apparently don't need it
> >
> > That's not true -- we had AMD systems in the past with broken MTRRs for
> > large memory configurations too,  Mostly it was pre revE though.
> 
> It should be easy enough to enable it for AMD as well, and it would also be 
> good to track down the one failure you found...  I don't *think* the 
> re-ordering of MTRR initialization should affect AMDs anymore than it does 
> Intel, but someone familiar with the boot code would have to do a quick audit 
> to be sure.

I looked back then when I had bisected it down and I admit I didn't spot the 
problem from source review. I think it came from the reordering so blacklisting 
AMD alone wouldn't have helped. Might have been some
subtle race (e.g. long ago we had such races in the MTRR code
triggered by the first HT CPUs) 

Anyways I just test booted latest git-x86 with your patches included on 
the QC system and it booted now. However it has both more RAM and newer CPUs 
(the original ones were pre-production, that is why I also didn't send you logs[1] ..) 
then when I tested originally. So this means either the problem was somewhere 
else or the different configuration hides it.

I guess you will hear about it if it's still broken on other machines.

Currently it looks good.

I think it should be enabled on AMD too though. If the reordering breaks
it then blacklisting won't help anyways.

-Andi

[1] but I checked the known errata and there was nothing related to MTRR.

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