From: Ingo Molnar Date: Tue, 15 Apr 2008 23:40:00 +0000 (+0200) Subject: mm: sparsemem memory_present() fix X-Git-Tag: v2.6.25~25 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bead9a3abd15710b0bdfd418daef606722d86282;p=pandora-kernel.git mm: sparsemem memory_present() fix Fix memory corruption and crash on 32-bit x86 systems. If a !PAE x86 kernel is booted on a 32-bit system with more than 4GB of RAM, then we call memory_present() with a start/end that goes outside the scope of MAX_PHYSMEM_BITS. That causes this loop to happily walk over the limit of the sparse memory section map: for (pfn = start; pfn < end; pfn += PAGES_PER_SECTION) { unsigned long section = pfn_to_section_nr(pfn); struct mem_section *ms; sparse_index_init(section, nid); set_section_nid(section, nid); ms = __nr_to_section(section); if (!ms->section_mem_map) ms->section_mem_map = sparse_encode_early_nid(nid) | SECTION_MARKED_PRESENT; 'ms' will be out of bounds and we'll corrupt a small amount of memory by encoding the node ID and writing SECTION_MARKED_PRESENT (==0x1) over it. The corruption might happen when encoding a non-zero node ID, or due to the SECTION_MARKED_PRESENT which is 0x1: mmzone.h:#define SECTION_MARKED_PRESENT (1UL<<0) The fix is to sanity check anything the architecture passes to sparsemem. This bug seems to be rather old (as old as sparsemem support itself), but the exact incarnation depended on random details like configs, which made this bug more prominent in v2.6.25-to-be. An additional enhancement might be to print a warning about ignored or trimmed memory ranges. Signed-off-by: Ingo Molnar Tested-by: Christoph Lameter Cc: Pekka Enberg Cc: Mel Gorman Cc: Nick Piggin Cc: Andrew Morton Cc: Rafael J. Wysocki Cc: Yinghai Lu Cc: KAMEZAWA Hiroyuki Signed-off-by: Linus Torvalds --- Reading git-diff-tree failed