[PATCH 1/1] MIPS: Fix "max_mapnr" assignment bug | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
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);
[Linux MIPS Home] [Kernel list] [Linux ARM list] [Linux] [Git] [Photo] [Yosemite News] [MIPS Architecture] [Linux SCSI] [Linux Hams] [Site Home]
![]() |
![]() |