On Mon, 7 Jan 2019 at 15:37, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxxxxx> 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"...
Got it. Thanks.
>
> thanks,
>
> greg k-h
