• Nishanth Aravamudan's avatar
    bootmem/sparsemem: remove limit constraint in alloc_bootmem_section · f5bf18fa
    Nishanth Aravamudan authored
    While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory
    Overcommit) on powerpc, we tripped the following:
    
      kernel BUG at mm/bootmem.c:483!
      cpu 0x0: Vector: 700 (Program Check) at [c000000000c03940]
          pc: c000000000a62bd8: .alloc_bootmem_core+0x90/0x39c
          lr: c000000000a64bcc: .sparse_early_usemaps_alloc_node+0x84/0x29c
          sp: c000000000c03bc0
         msr: 8000000000021032
        current = 0xc000000000b0cce0
        paca    = 0xc000000001d80000
          pid   = 0, comm = swapper
      kernel BUG at mm/bootmem.c:483!
      enter ? for help
      [c000000000c03c80] c000000000a64bcc
      .sparse_early_usemaps_alloc_node+0x84/0x29c
      [c000000000c03d50] c000000000a64f10 .sparse_init+0x12c/0x28c
      [c000000000c03e20] c000000000a474f4 .setup_arch+0x20c/0x294
      [c000000000c03ee0] c000000000a4079c .start_kernel+0xb4/0x460
      [c000000000c03f90] c000000000009670 .start_here_common+0x1c/0x2c
    
    This is
    
            BUG_ON(limit && goal + size > limit);
    
    and after some debugging, it seems that
    
    	goal = 0x7ffff000000
    	limit = 0x80000000000
    
    and sparse_early_usemaps_alloc_node ->
    sparse_early_usemaps_alloc_pgdat_section calls
    
    	return alloc_bootmem_section(usemap_size() * count, section_nr);
    
    This is on a system with 8TB available via the AMS pool, and as a quirk
    of AMS in firmware, all of that memory shows up in node 0.  So, we end
    up with an allocation that will fail the goal/limit constraints.
    
    In theory, we could "fall-back" to alloc_bootmem_node() in
    sparse_early_usemaps_alloc_node(), but since we actually have HOTREMOVE
    defined, we'll BUG_ON() instead.  A simple solution appears to be to
    unconditionally remove the limit condition in alloc_bootmem_section,
    meaning allocations are allowed to cross section boundaries (necessary
    for systems of this size).
    
    Johannes Weiner pointed out that if alloc_bootmem_section() no longer
    guarantees section-locality, we need check_usemap_section_nr() to print
    possible cross-dependencies between node descriptors and the usemaps
    allocated through it.  That makes the two loops in
    sparse_early_usemaps_alloc_node() identical, so re-factor the code a
    bit.
    
    [akpm@linux-foundation.org: code simplification]
    Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
    Cc: Dave Hansen <haveblue@us.ibm.com>
    Cc: Anton Blanchard <anton@au1.ibm.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
    Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
    Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
    Acked-by: default avatarMel Gorman <mgorman@suse.de>
    Cc: <stable@vger.kernel.org>	[3.3.1]
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    f5bf18fa
bootmem.c 20.7 KB