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]

Message-ID: <20100310215018.GD24353@flint.arm.linux.org.uk>
Date:	Wed, 10 Mar 2010 21:50:18 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	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 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.
2. How does memory get allocated for creating things like page tables?

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?

Where are patches 1 to 4?

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

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/