Fix "max_mapnr" assignment bug for high-memory enabled kernels running on
platforms with no high memory
Currently, high memory enabled kernels always set "max_mapnr" equal to
"highend_pfn", but "highend_pfn" is only valid if high memory is available on
the platform. The proposed fix is to only use "highend_pfn" in the assignment
when it is valid (non-zero). In my particular case, this bug was manifesting
itself via the "pfn_valid()" macro, with "CONFIG_FLATMEM" defined.
Signed-off-by: Victor Williams <williavi@xxxxxxxxx>
Signed-off-by: Sudharsan Vijayaraghavan <vijayas@xxxxxxxxx>
---
init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- old/arch/mips/mm/init.c 2008-08-06 11:19:01.000000000 -0500
+++ new/arch/mips/mm/init.c 2008-08-13 11:17:03.000000000 -0500
@@ -388,13 +388,13 @@
unsigned long codesize, reservedpages, datasize, initsize;
unsigned long tmp, ram;
+ max_mapnr = max_low_pfn;
#ifdef CONFIG_HIGHMEM
#ifdef CONFIG_DISCONTIGMEM
#error "CONFIG_HIGHMEM and CONFIG_DISCONTIGMEM dont work together yet"
#endif
- max_mapnr = highend_pfn;
-#else
- max_mapnr = max_low_pfn;
+ if (highend_pfn)
+ max_mapnr = highend_pfn;
#endif
high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT);
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
