linux-kernel - Re: x86-64: memset()/memcpy() not fully standards compliant

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: <20120106194400.GX11715@one.firstfloor.org>
Date:	Fri, 6 Jan 2012 20:44:00 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	Andi Kleen <andi@...stfloor.org>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: x86-64: memset()/memcpy() not fully standards compliant

> enough beyond 292G. At some later point ->node_page_cgroup[]
> also exceeds 4G. Finally, the phys-to-machine mapping (which gets
> resized during boot) exceeds 4G when crossing the 2T boundary.

Ok it's moot then because the old systems with problem didn't have
that much memory. So you could do without an errata workaround
and just extend the moves at the minor cost of a few prefixes
(I think that is what you did in your patch)

Only hope there are no new chips with similar issues...

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/