linux-kernel - Re: [PATCH] trim memory not covered by WB MTRRs

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: <200706260838.05737.jbarnes@virtuousgeek.org>
Date:	Tue, 26 Jun 2007 08:38:05 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Jesse Barnes <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Yinghai Lu <yhlu.kernel@...il.com>
Subject: Re: [PATCH] trim memory not covered by WB MTRRs

On Tuesday, June 26, 2007 8:02:49 am Andi Kleen wrote:
> On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote:
> > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> > > > This patch fixes a bug in the last patch that caused the code to
> > > > run on non-Intel machines (AMD machines apparently don't need it
> > >
> > > Actually the problem can happen on AMD too, but the symptoms can
> > > be different and there can be more wrong than just the MTRRs.
> >
> > I should have been more specific in the changelog.  My understanding is
> > that AMD systems don't need it for memory above 4G, and since the code
>
> AMD systems need MTRRs to get cached memory too, or what is your point?

My point is that yes, this problem can happen on AMD, but the code doesn't 
handle the problems that AMD systems might have, since it doesn't look for 
problems in low memory (e.g. if you have an AMD system with 6G of memory, the 
code will probably trim everything above 4G since it doesn't know about the 
new AMD mapping stuff from RevE), as Eric pointed out.

Both you and Eric say you've seen AMD systems with problems, but handling them 
would make the code more complex than it is now, and I haven't seen the 
actual reports (memory maps & MTRR setups) so I can't really fix them anyway.  
And since this patch solves real problems as-is, it seems like we should push 
it upstream then rework it, if necessary (i.e. real user machines with this 
problem) later.

What do you think?

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