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]

Date:	Thu, 7 Jun 2007 19:00:45 -0400 (EDT)
From:	Justin Piszcz <jpiszcz@...idpixels.com>
To:	Jesse Barnes <jesse.barnes@...el.com>
cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] trim memory not covered by WB MTRRs



On Thu, 7 Jun 2007, Jesse Barnes wrote:

> On some machines, buggy BIOSes don't properly setup WB MTRRs to
> cover all available RAM, meaning the last few megs (or even gigs)
> of memory will be marked uncached.  Since Linux tends to allocate
> from high memory addresses first, this causes the machine to be
> unusably slow as soon as the kernel starts really using memory
> (i.e. right around init time).
>
> This patch works around the problem by scanning the MTRRs at
> boot and figuring out whether the current end_pfn value (setup
> by early e820 code) goes beyond the highest WB MTRR range, and
> if so, trimming it to match.  A fairly obnoxious KERN_WARNING
> is printed too, letting the user know that not all of their
> memory is available due to a likely BIOS bug.
>
> Something similar could be done on i386 if needed, but the boot
> ordering would be slightly different, since the MTRR code on i386
> depends on the boot_cpu_data structure being setup.
>
> This patch incorporates the feedback from Eric and Andi:
>  - use MAX_VAR_RANGES instead of NUM_VAR_RANGES
>  - move array declaration to header file as an extern
>  - add command line disable option "disable_mtrr_trim"
>  - don't run the trim code if the MTRR default type is cacheable
>  - don't run the trim code on non-Intel machines
>
> Justin, feel free to test again if you have time and add your
> "Tested-by" signoff.
>
> Andi, as for large pages, do you think this is ok as is, or should
> I trim a larger granularity?  If so, what granularity?
>
> Signed-off-by:  Jesse Barnes <jesse.barnes@...el.com>
>
> Thanks,
> Jesse
>

v1 of your patch:

top - 18:53:46 up 1 day, 1 min, 27 users,  load average: 2.82, 1.11,
0.90
Tasks: 356 total,   7 running, 348 sleeping,   1 stopped,   0 zombie
Cpu(s):  2.2%us,  0.4%sy,  0.0%ni, 97.0%id,  0.1%wa,  0.0%hi,  0.2%si,
0.0%st
Mem:   8039576k total,  7962376k used,    77200k free,      716k buffers
Swap: 16787768k total,      128k used, 16787640k free,  6713332k cached

v2 of your patch: (dmesg also attached)

top - 18:58:59 up 2 min,  4 users,  load average: 0.12, 0.13, 0.05
Tasks: 155 total,   1 running, 154 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.0%us,  1.1%sy,  0.5%ni, 94.8%id,  1.5%wa,  0.0%hi,  0.0%si,
0.0%st
Mem:   8039576k total,   982192k used,  7057384k free,     1876k buffers
Swap: 16787768k total,        0k used, 16787768k free,   114492k cached

If the box has no issues over the next 8 hours with me pounding it with 
backups, bzip2s etc I'll consider it good, so far it boots fine etc, no 
issues, but I'll let it cook for a bit.  Will update tomorrow.

Thanks,

Justin.
View attachment "dmesg2.txt" of type "TEXT/plain" (49579 bytes)