Subject: + memcg-oom-lock-mem_cgroup_print_oom_info.patch added to -mm tree To: mhocko@xxxxxxx,hannes@xxxxxxxxxxx,kamezawa.hiroyu@xxxxxxxxxxxxxx,kosaki.motohiro@xxxxxxxxxxxxxx,rientjes@xxxxxxxxxx From: akpm@xxxxxxxxxxxxxxxxxxxx Date: Wed, 11 Dec 2013 13:53:41 -0800 The patch titled Subject: memcg, oom: lock mem_cgroup_print_oom_info has been added to the -mm tree. Its filename is memcg-oom-lock-mem_cgroup_print_oom_info.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/memcg-oom-lock-mem_cgroup_print_oom_info.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/memcg-oom-lock-mem_cgroup_print_oom_info.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Michal Hocko <mhocko@xxxxxxx> Subject: memcg, oom: lock mem_cgroup_print_oom_info mem_cgroup_print_oom_info uses a static buffer (memcg_name) to store the name of the cgroup. This is not safe as pointed out by David Rientjes because memcg oom is locked only for its hierarchy and nothing prevents another parallel hierarchy to trigger oom as well and overwrite the already in-use buffer. This patch introduces oom_info_lock hidden inside mem_cgroup_print_oom_info which is held throughout the function. It makes access to memcg_name safe and as a bonus it also prevents parallel memcg ooms to interleave their statistics which would make the printed data hard to analyze otherwise. Signed-off-by: Michal Hocko <mhocko@xxxxxxx> Cc: Johannes Weiner <hannes@xxxxxxxxxxx> Cc: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> Cc: David Rientjes <rientjes@xxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/memcontrol.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff -puN mm/memcontrol.c~memcg-oom-lock-mem_cgroup_print_oom_info mm/memcontrol.c --- a/mm/memcontrol.c~memcg-oom-lock-mem_cgroup_print_oom_info +++ a/mm/memcontrol.c @@ -1647,13 +1647,13 @@ static void move_unlock_mem_cgroup(struc */ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p) { - struct cgroup *task_cgrp; - struct cgroup *mem_cgrp; /* - * Need a buffer in BSS, can't rely on allocations. The code relies - * on the assumption that OOM is serialized for memory controller. - * If this assumption is broken, revisit this code. + * protects memcg_name and makes sure that parallel ooms do not + * interleave */ + static DEFINE_SPINLOCK(oom_info_lock); + struct cgroup *task_cgrp; + struct cgroup *mem_cgrp; static char memcg_name[PATH_MAX]; int ret; struct mem_cgroup *iter; @@ -1662,6 +1662,7 @@ void mem_cgroup_print_oom_info(struct me if (!p) return; + spin_lock(&oom_info_lock); rcu_read_lock(); mem_cgrp = memcg->css.cgroup; @@ -1730,6 +1731,7 @@ done: pr_cont("\n"); } + spin_unlock(&oom_info_lock); } /* _ Patches currently in -mm which might be from mhocko@xxxxxxx are mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch mm-memcg-fix-race-condition-between-memcg-teardown-and-swapin.patch mm-memcg-do-not-allow-task-about-to-oom-kill-to-bypass-the-limit.patch mm-memcg-avoid-oom-notification-when-current-needs-access-to-memory-reserves.patch mm-mempolicy-remove-unneeded-functions-for-uma-configs.patch memcg-fix-kmem_account_flags-check-in-memcg_can_account_kmem.patch memcg-make-memcg_update_cache_sizes-static.patch introduce-for_each_thread-to-replace-the-buggy-while_each_thread.patch oom_kill-change-oom_killc-to-use-for_each_thread.patch oom_kill-has_intersects_mems_allowed-needs-rcu_read_lock.patch oom_kill-add-rcu_read_lock-into-find_lock_task_mm.patch mm-page_alloc-allow-__gfp_nofail-to-allocate-below-watermarks-after-reclaim.patch mm-memblock-debug-correct-displaying-of-upper-memory-boundary.patch mm-memblock-debug-dont-free-reserved-array-if-arch_discard_memblock.patch mm-bootmem-remove-duplicated-declaration-of-__free_pages_bootmem.patch mm-memblock-remove-unnecessary-inclusions-of-bootmemh.patch mm-memblock-drop-warn-and-use-smp_cache_bytes-as-a-default-alignment.patch mm-memblock-reorder-parameters-of-memblock_find_in_range_node.patch mm-memblock-switch-to-use-numa_no_node-instead-of-max_numnodes.patch mm-memblock-add-memblock-memory-allocation-apis.patch mm-memblock-add-memblock-memory-allocation-apis-fix.patch mm-init-use-memblock-apis-for-early-memory-allocations.patch mm-printk-use-memblock-apis-for-early-memory-allocations.patch mm-page_alloc-use-memblock-apis-for-early-memory-allocations.patch mm-power-use-memblock-apis-for-early-memory-allocations.patch lib-swiotlbc-use-memblock-apis-for-early-memory-allocations.patch lib-cpumaskc-use-memblock-apis-for-early-memory-allocations.patch mm-sparse-use-memblock-apis-for-early-memory-allocations.patch mm-hugetlb-use-memblock-apis-for-early-memory-allocations.patch mm-page_cgroup-use-memblock-apis-for-early-memory-allocations.patch mm-percpu-use-memblock-apis-for-early-memory-allocations.patch mm-memory_hotplug-use-memblock-apis-for-early-memory-allocations.patch drivers-firmware-memmapc-use-memblock-apis-for-early-memory-allocations.patch arch-arm-kernel-use-memblock-apis-for-early-memory-allocations.patch arch-arm-mm-initc-use-memblock-apis-for-early-memory-allocations.patch arch-arm-mach-omap2-omap_hwmodc-use-memblock-apis-for-early-memory-allocations.patch lib-show_memc-show-num_poisoned_pages-when-oom.patch memcg-oom-lock-mem_cgroup_print_oom_info.patch proc-fix-the-potential-use-after-free-in-first_tid.patch proc-change-first_tid-to-use-while_each_thread-rather-than-next_thread.patch proc-dont-abuse-group_leader-in-proc_task_readdir-paths.patch proc-fix-f_pos-overflows-in-first_tid.patch linux-next.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html