On Fri 22-11-13 14:34:16, Andrew Morton wrote: > Subject: + mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch > added to -mm tree > To: > [email protected],[email protected],[email protected],[email protected],[email protected] > From: [email protected] > Date: Fri, 22 Nov 2013 14:34:16 -0800 > > > The patch titled > Subject: mm: memcg: do not declare OOM from __GFP_NOFAIL allocations > has been added to the -mm tree. Its filename is > mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch > > This patch should soon appear at > > http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch > and later at > > http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.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: Johannes Weiner <[email protected]> > Subject: mm: memcg: do not declare OOM from __GFP_NOFAIL allocations > > 84235de394d9 ("fs: buffer: move allocation failure loop into the > allocator") started recognizing __GFP_NOFAIL in memory cgroups but forgot > to disable the OOM killer. > > Any task that does not fail allocation will also not enter the OOM > completion path. So don't declare an OOM state in this case or it'll be > leaked and the task be able to bypass the limit until the next > userspace-triggered page fault cleans up the OOM state. > > Reported-by: William Dauchy <[email protected]>
/me confused. Is this the same issue as reported by William? http://comments.gmane.org/gmane.linux.kernel.mm/108113 Or was there any other reported? > Signed-off-by: Johannes Weiner <[email protected]> > Cc: Michal Hocko <[email protected]> > Cc: David Rientjes <[email protected]> > Cc: <[email protected]> [3.12.x] > Signed-off-by: Andrew Morton <[email protected]> The fix makes sense to me though. Acked-by: Michal Hocko <[email protected]> > > --- > > mm/memcontrol.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff -puN > mm/memcontrol.c~mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations > mm/memcontrol.c > --- > a/mm/memcontrol.c~mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations > +++ a/mm/memcontrol.c > @@ -2696,6 +2696,9 @@ static int __mem_cgroup_try_charge(struc > if (unlikely(task_in_memcg_oom(current))) > goto bypass; > > + if (gfp_mask & __GFP_NOFAIL) > + oom = false; > + > /* > * We always charge the cgroup the mm_struct belongs to. > * The mm_struct's mem_cgroup changes on task migration if the > _ > > Patches currently in -mm which might be from [email protected] are > > origin.patch > mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch > mm-memcg-avoid-oom-notification-when-current-needs-access-to-memory-reserves.patch > proc-meminfo-provide-estimated-available-memory.patch > swap-add-a-simple-detector-for-inappropriate-swapin-readahead-fix.patch > debugging-keep-track-of-page-owners.patch > -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
