Ralf Baechle wrote:
On Wed, Apr 16, 2008 at 03:32:22PM +0200, Kevin D. Kissell wrote:
arch/mips/kernel/setup.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index f8a535a..a6a0d62 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -336,6 +336,10 @@ static void __init bootmem_init(void)
#endif
max_low_pfn = PFN_DOWN(HIGHMEM_START);
}
+ /*
+ * Propagate final value of max_low_pfn to max_pfn
+ */
+ max_pfn = max_low_pfn;
That will be incorrect for systems with highmem. So I think the right
fix is to replace all references to max_pfn in vpe.c with max_low_pfn.
Which will still be incorrect for systems with highmem, right? The reason
I propose fixing max_pfn instead of just hacking vpe.c is that, as per my
email of a couple of weeks ago, there are other, architecture independent,
bits of code in the 2.6.24 kernel where max_pfn is assumed to be sane,
and the value of zero may result in otherwise inexplicable Bad Things
happening. So even if you want to change vpe.c to use max_low_pfn
instead of max_pfn, I believe that we really want that patch to setup.c
until such time as we've verified that the kernel is max_pfn-free.
Regards,
Kevin K.
