On Tue, Mar 05, 2019 at 10:13:24AM -0500, Qian Cai wrote:
> On Tue, 2019-03-05 at 14:42 +0000, Mel Gorman wrote:
> > On Mon, Mar 04, 2019 at 10:55:04PM -0500, Qian Cai wrote:
> > > Reverted the patches below from linux-next seems fixed a crash while running
> > > LTP
> > > oom01.
> > >
> > > 915c005358c1 mm, compaction: Capture a page under direct compaction -fix
> > > e492a5711b67 mm, compaction: capture a page under direct compaction
> > >
> > > Especially, just removed this chunk along seems fixed the problem.
> > >
> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -2227,10 +2227,10 @@ compact_zone(struct compact_control *cc, struct
> > > capture_control *capc)
> > > }
> > >
> > > /* Stop if a page has been captured */
> > > - if (capc && capc->page) {
> > > - ret = COMPACT_SUCCESS;
> > > - break;
> > > - }
> > >
> >
> > It's hard to make sense of how this is connected to the bug. The
> > out-of-bounds warning would have required page flags to be corrupted
> > quite badly or maybe the use of an uninitialised page. How reproducible
> > has this been for you? I just ran the test 100 times with UBSAN and page
> > alloc debugging enabled and it completed correctly.
> >
>
> I did manage to reproduce this every time by running oom01 within 3 tries on
> this x86_64 server and was unable to reproduce on arm64 and ppc64le servers so
> far.
>
Ok, so there is something specific about the machine or the kernel
config that is at play. You're seeing slub issues, page state issues
etc. Have you seen this on any other x86-based machine? Also please post
your kernel config. Are you certain that removing the block from your
first email avoids any issue triggering?
--
Mel Gorman
SUSE Labs
