On Mon, Nov 25, 2013 at 04:09:25PM +0100, Michal Hocko wrote: > 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?
No, this is different. He sent me an email in private, noting that this hunk - which he had in his test patches based on 3.10 - was missing upstream. It got lost in the back and forth between 3.2 for azurIt, 3.10 for William, and upstream. > > 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]> Thanks. -- 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
