On Thu, Jul 02, 2015 at 05:16:01PM +0200, Alexander Sverdlin wrote: > Commit f9a7febd leads to a fact that mapstart and therefore a page bitmap for > bootmem allocator immediately follows initrd_end. This doesn't always work > well on Octeon, where there are holes in PFN ranges (refer to 5b3b1688 and > 4MB-aligned PFN allocation). Depending on the inird location it could happen, > that mapstart would be in an area not allocated by plat_mem_setup() in > arch/mips/cavium-octeon/setup.c, but in the alignment hole between initrd and > the next PFN area. Later on this memory will be unconditionally made available > to buddy allocator at the end of free_all_bootmem_core() (mm/bootmem.c). > All of this results in Linux using the memory not designated for Linux in > Octeon's plat_mem_setup(), which in turn means corruption of the memory used > by another OS/baremetal code on the same SoC. > > It doesn't look to me as a problem of Octeon platform code, but rather as an > inability of f9a7febd to deal correctly with the fragmented memory-mappings. > Proposed fix moves the check for initrd address to the same calculation-loop > in bootmem_init() (arch/mips/kernel/setup.c), which also accounts for kernel > code location. This should result in mapstart located starting from the first > PFN area after kernel code AND initrd. > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx> Appears reasonable. Applied. Thanks, Ralf
