On Mon, 7 Jan 2019 at 17:17, Minchan Kim <minchan@xxxxxxxxxx> wrote:
>
> On Mon, Jan 07, 2019 at 04:37:37PM +0530, Amit Pundir wrote:
> > Hi Minchan,
> >
> > Kindly review your 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")
> >
> > 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.
> >
> > The original patch series https://lkml.org/lkml/2016/10/12/77 was sort
> > of NACked for stable https://lkml.org/lkml/2016/10/12/655 because no
> > one else reported this OOM behavior on lkml. And the only reason I'm
> > bringing this up again, for stable-4.9.y tree, is that msm-4.9 Android
> > trees cherry-picked this whole series as is for their production devices.
> >
> > Are there any concerns around this series, in case I submit it to
> > stable mailing list for v4.9.y?
>
> Actually, it was not NAK. Other MM guy wanted to backport but I didn't
> intentionally because I didn't see other reports at that time.
>
> However, after that, I got a private email from some other kernel team
> and debugged together. It hit this problem and solved by above patches
> so they backported it.
> If you say Android already check-picked them, it's third time I heard
> the problem(If they really pick those patch due to some problem) since
> we merge those patches into upstream.
> So, I belive it's worth to merge if someone could volunteer.
This is where it gets tricky, Code Aurora cherry-picked these patches
for their Android v4.9.y tree, where they get applied cleanly i.e. no
backport needed. But there is no way to tell if these patches indeed
solved an OOM bug or two for them.
So let me put it this way, is it safe to apply this series on v4.9
kernel? Or should I be wary of regressions?
Regards,
Amit Pundir
>
> Thanks.
