• Johannes Weiner's avatar
    mm: memcg: fix test for child groups · 696ac172
    Johannes Weiner authored
    When memcg code needs to know whether any given memcg has children, it
    uses the cgroup child iteration primitives and returns true/false
    depending on whether the iteration loop is executed at least once or
    not.
    
    Because a cgroup's list of children is RCU protected, these primitives
    require the RCU read-lock to be held, which is not the case for all
    memcg callers.  This results in the following splat when e.g.  enabling
    hierarchy mode:
    
      WARNING: CPU: 3 PID: 1 at kernel/cgroup.c:3043 css_next_child+0xa3/0x160()
      CPU: 3 PID: 1 Comm: systemd Not tainted 3.12.0-rc5-00117-g83f11a9c-dirty #18
      Hardware name: LENOVO 3680B56/3680B56, BIOS 6QET69WW (1.39 ) 04/26/2012
      Call Trace:
        dump_stack+0x54/0x74
        warn_slowpath_common+0x78/0xa0
        warn_slowpath_null+0x1a/0x20
        css_next_child+0xa3/0x160
        mem_cgroup_hierarchy_write+0x5b/0xa0
        cgroup_file_write+0x108/0x2a0
        vfs_write+0xbd/0x1e0
        SyS_write+0x4c/0xa0
        system_call_fastpath+0x16/0x1b
    
    In the memcg case, we only care about children when we are attempting to
    modify inheritable attributes interactively.  Racing with deletion could
    mean a spurious -EBUSY, no problem.  Racing with addition is handled
    just fine as well through the memcg_create_mutex: if the child group is
    not on the list after the mutex is acquired, it won't be initialized
    from the parent's attributes until after the unlock.
    Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
    Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    696ac172
memcontrol.c 186 KB