Re: [for-4.9.y] Patch series "use up highorder free pages before OOM", v3.

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Mon, Jan 07, 2019 at 03:25:42PM +0530, Amit Pundir wrote:
> On Mon, 7 Jan 2019 at 15:18, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Jan 07, 2019 at 03:10:35PM +0530, Amit Pundir wrote:
> > > Hi Greg,
> > >
> > > Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
> > >
> > > 88ed365ea227 ("mm: don't steal highatomic pageblock")
> > > 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM")
> > > 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
> > >
> > > The original 4 patch series is archived here
> > > https://lkml.org/lkml/2016/10/12/77 for review.
> > > One of the patch from this series:
> > > 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic")
> > > has already been picked up for 4.9.y and 4.4.y.
> > >
> > > I ran into these fixes in one of the msm-4.9(android) trees.
> > > Cherry-picked and build tested on Linux 4.9.148 for
> > > ARCH=arm/arm64 defconfig.
> > >
> > > Only the first patch from this series can be applied cleanly on
> > > v4.4.y, while others fail to apply cleanly due to OOM rework done in
> > > v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection").
> > > Plus I don't see this series backported to v4.4 in any of the
> > > msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
> >
> > Can you get an ack from the mm developers that these really are viable
> > for backporting to older kernel trees as they solve a real issue?
> 
> I forgot to mention that marking the original series for stable
> (v4.4+) was discussed as well, and was sort of NACked
> https://lkml.org/lkml/2016/10/12/655 because no one else reported this
> OOM behavior. And the only reason I submitted this series for v4.9 is
> msm-4.9 Android trees which cherry-picked this whole series as is.

I remember that thread, which is why I asked for explicit "yes this is
good" for 4.9.  Just because a crazy vendor dropped patches in their
tree is not always a good reason to actually put them in everyone's
tree.  That vendor is liable for the fallout as-is, do not transfer that
liability to upstream when they explicitly said "do not apply these"...

thanks,

greg k-h