linux-kernel - Re: [PATCH 5/6] early_res: seperate common memmap func from e820.c to fw

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:	Wed, 10 Mar 2010 14:05:42 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 5/6] early_res: seperate common memmap func from e820.c
 to fw_memmap.c

On 03/10/2010 01:50 PM, Russell King wrote:
> On Wed, Mar 10, 2010 at 01:24:26PM -0800, Yinghai Lu wrote:
>> +/* How much should we pad RAM ending depending on where it is? */
>> +static unsigned long __init ram_alignment(resource_size_t pos)
>> +{
>> +	unsigned long mb = pos >> 20;
>> +
>> +	/* To 64kB in the first megabyte */
>> +	if (!mb)
>> +		return 64*1024;
>> +
>> +	/* To 1MB in the first 16MB */
>> +	if (mb < 16)
>> +		return 1024*1024;
>> +
>> +	/* To 64MB for anything above that */
>> +	return 64*1024*1024;
>> +}
> 
> This doesn't make sense for generic code.
> 
> 1. All architectures do not have RAM starting at physical address 0.
> 2. What about architectures which have relatively little memory (maybe
>    16MB total) split into four chunks of 4MB spaced at 512MB ?

> 
> Other comments:
> 
> 1. It doesn't support mem=size@...e, which is used extensively on ARM.

current x86, need to use exactmap...
so could add sth in arch/arm/setup.c to set it.


> 2. How does memory get allocated for creating things like page tables?
find_fw_memmap_area
rerserve_early

> 
> Currently, bootmem supports ARM very well with support for flatmem,
> sparsemem and discontigmem models (the latter being deprecated).  Can
> this code support all three models?
should be ok.
> 
> Where are patches 1 to 4?

my bad, it still have 1/4, 2/4, 3/4, 4/4

> 
> Lastly, why exactly is bootmem being eliminated?  Bootmem offers more
> flexible functionality than this e820 code appears at first read-through
> seems to.
less layer before slab...

fw_memmap.c could be simplified by keeping more stuff in arch/x86/kernel/e820.c
will have one fw_mem_internal.h and only be included by fw_memmap.c and arch fw_memmap.c.

YH



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