linux-kernel - Re: [PATCH] x86: fix pte allocation in "x86: introduce init_memory

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: <4861C03A.90107@goop.org>
Date:	Tue, 24 Jun 2008 23:49:14 -0400
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: fix pte allocation in "x86: introduce init_memory_mapping
 for 32bit"

Yinghai Lu wrote:
> thanks.
>
> my test system never use the area from table_start to table_end. and I
> wonder why init_pgtable is that big..

This code looks just like the 64-bit code (I guess it's becoming prime 
for unification), and I'd just spent some time debugging a bug in Xen64 
caused by an overrun of the allocated area when creating non-PSE 
mappings of physical memory.  I didn't observe a specific problem with 
this code, but consistency and pattern matching made it seem like a 
necessary addition.  It only ends up reserving the amount of space 
actually used, so there's no wasted memory.

If you use PSE to create the mapping and have enough mapped pages anyway 
(small kernel), then you may not end up using any of this space.

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