Skip to content
  • Laurent Dufour's avatar
    mm/cgroup: avoid panic when init with low memory · bfc7228b
    Laurent Dufour authored
    The system may panic when initialisation is done when almost all the
    memory is assigned to the huge pages using the kernel command line
    parameter hugepage=xxxx.  Panic may occur like this:
    
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc000000000302b88
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=2048 [    0.082424] NUMA
      pSeries
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-15-generic #16-Ubuntu
      task: c00000021ed01600 task.stack: c00000010d108000
      NIP: c000000000302b88 LR: c000000000270e04 CTR: c00000000016cfd0
      REGS: c00000010d10b2c0 TRAP: 0300   Not tainted (4.9.0-15-generic)
      MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>[ 0.082770]   CR: 28424422  XER: 00000000
      CFAR: c0000000003d28b8 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1
      GPR00: c000000000270e04 c00000010d10b540 c00000000141a300 c00000010fff6300
      GPR04: 0000000000000000 00000000026012c0 c00000010d10b630 0000000487ab0000
      GPR08: 000000010ee90000 c000000001454fd8 0000000000000000 0000000000000000
      GPR12: 0000000000004400 c00000000fb80000 00000000026012c0 00000000026012c0
      GPR16: 00000000026012c0 0000000000000000 0000000000000000 0000000000000002
      GPR20: 000000000000000c 0000000000000000 0000000000000000 00000000024200c0
      GPR24: c0000000016eef48 0000000000000000 c00000010fff7d00 00000000026012c0
      GPR28: 0000000000000000 c00000010fff7d00 c00000010fff6300 c00000010d10b6d0
      NIP mem_cgroup_soft_limit_reclaim+0xf8/0x4f0
      LR do_try_to_free_pages+0x1b4/0x450
      Call Trace:
        do_try_to_free_pages+0x1b4/0x450
        try_to_free_pages+0xf8/0x270
        __alloc_pages_nodemask+0x7a8/0xff0
        new_slab+0x104/0x8e0
        ___slab_alloc+0x620/0x700
        __slab_alloc+0x34/0x60
        kmem_cache_alloc_node_trace+0xdc/0x310
        mem_cgroup_init+0x158/0x1c8
        do_one_initcall+0x68/0x1d0
        kernel_init_freeable+0x278/0x360
        kernel_init+0x24/0x170
        ret_from_kernel_thread+0x5c/0x74
      Instruction dump:
      eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 4e800020 3d230001 e9499a42 3d220004
      3929acd8 794a1f24 7d295214 eac90100 <e9360000> 2fa90000 419eff74 3b200000
      ---[ end trace 342f5208b00d01b6 ]---
    
    This is a chicken and egg issue where the kernel try to get free memory
    when allocating per node data in mem_cgroup_init(), but in that path
    mem_cgroup_soft_limit_reclaim() is called which assumes that these data
    are allocated.
    
    As mem_cgroup_soft_limit_reclaim() is best effort, it should return when
    these data are not yet allocated.
    
    This patch also fixes potential null pointer access in
    mem_cgroup_remove_from_trees() and mem_cgroup_update_tree().
    
    Link: http://lkml.kernel.org/r/1487856999-16581-2-git-send-email-ldufour@linux.vnet.ibm.com
    
    
    Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
    Acked-by: default avatarMichal Hocko <mhocko@suse.com>
    Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
    Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    bfc7228b