MIPS: bootmem: Don't use memory holes for page bitmap

MIPS: bootmem: Don't use memory holes for page bitmap

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 <[email protected]>
Cc: [email protected]
Cc: David Daney <[email protected]>
Cc: Zubair Lutfullah Kakakhel <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: Andreas Herrmann <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Steven J. Hill <[email protected]>
Cc: Yusuf Khan <[email protected]>
Cc: Michael Kreuzer <[email protected]>
Cc: Aaro Koskinen <[email protected]>
Patchwork: https://patchwork.linux-mips.org/patch/10594/
Signed-off-by: Ralf Baechle <[email protected]>