Re: + mm-memcg-do-not-declare-oom-from-__gfp_nofail-allocations.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: hannes@xxxxxxxxxxx,mhocko@xxxxxxx,rientjes@xxxxxxxxxx,stable@xxxxxxxxxxxxxxx,wdauchy@xxxxxxxxx
> > From: akpm@xxxxxxxxxxxxxxxxxxxx
> > 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 <hannes@xxxxxxxxxxx>
> > 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 <wdauchy@xxxxxxxxx>
> 
> /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 <hannes@xxxxxxxxxxx>
> > Cc: Michal Hocko <mhocko@xxxxxxx>
> > Cc: David Rientjes <rientjes@xxxxxxxxxx>
> > Cc: <stable@xxxxxxxxxxxxxxx>	[3.12.x]
> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> 
> The fix makes sense to me though.
> Acked-by: Michal Hocko <mhocko@xxxxxxx>

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]