linux-mips
[Top] [All Lists]

Re: [PATCH] mips: fix start of free memory when using initrd

To: Greg Ungerer <gerg@snapgear.com>
Subject: Re: [PATCH] mips: fix start of free memory when using initrd
From: David Daney <ddaney@caviumnetworks.com>
Date: Fri, 10 Sep 2010 09:23:08 -0700
Cc: linux-mips@linux-mips.org
In-reply-to: <4C89CBDA.1030309@snapgear.com>
References: <201009080550.o885ohjD014188@goober.internal.moreton.com.au> <4C891863.1080602@caviumnetworks.com> <4C89CBDA.1030309@snapgear.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6
On 09/09/2010 11:10 PM, Greg Ungerer wrote:

Hi David,

David Daney wrote:
[...]
We have the attached patch (plus a few more hacks), I don't think it
is universally safe to change the calculation of reserved_end.
Although the patch has some code formatting problems you might
consider using it as a starting point.>
I don't use the Cavium u-boot boot loader on this. (And don't use any
of the named blocks, or other data struct passing from the boot loader
to the kernel). So the patch is not really useful for me.

But I am interested, why do you think it is not safe to change
reserved_end?

For Octeon it is probably safe, but there is a reason that this complex logic for restricting the usable memory ranges exists. Other targets require it, so great care must be taken not to break the non-octeon targets.


There is the possible overlap of the kernels bootmem setup data
that is not checked (which sparc does for example). But otherwise
what problems do you see here?


I lack the imagination necessary to come up with a failing scenario, but I am also paranoid, so I see danger everywhere.

David Daney


<Prev in Thread] Current Thread [Next in Thread>