On Tue, Mar 11, 2014 at 01:47:24PM -0700, Davidlohr Bueso wrote:
> On Tue, 2014-03-11 at 16:45 -0400, Sasha Levin wrote:
> > On 03/11/2014 04:30 PM, Andrew Morton wrote:
> > > All I can think is that find_vma() went and returned a vma from a
> > > different mm, which would be odd. How about I toss this in there?
> > >
> > > --- a/mm/vmacache.c~a
> > > +++ a/mm/vmacache.c
> > > @@ -72,8 +72,10 @@ struct vm_area_struct *vmacache_find(str
> > > for (i = 0; i < VMACACHE_SIZE; i++) {
> > > struct vm_area_struct *vma = current->vmacache[i];
> > >
> > > - if (vma && vma->vm_start <= addr && vma->vm_end > addr)
> > > + if (vma && vma->vm_start <= addr && vma->vm_end > addr)
> > > {
> > > + BUG_ON(vma->vm_mm != mm);
> > > return vma;
> > > + }
> > > }
> >
> > [ 243.565794] kernel BUG at mm/vmacache.c:76!
>
> and this is also part of the DEBUG_PAGEALLOC + trinity combo! I suspect
> the root cause it the same as Fengguang's report.
btw, I added a (ugly) script to trinity.git this afternoon:
https://github.com/kernelslacker/trinity/commit/b6cfe63ea5b205a34bc6c5698e5b766dfcddad1d
which should make reproducing VM related bugs happen a lot faster.
While chasing one particular issue, that script has hit 2-3 others in my
testing so far today (All already known).
It would be really good if people other than me & Sasha started running stuff
like this occasionally
to try and get some of the more annoying things fixed up faster. Though it's
only really
useful with debug kernels, and I know from past experience that asking people
to try running things
with debug options enabled is like pulling teeth..
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
