Re: mm: mmap_sem lock assertion failure in __mlock_vma_pages_range

[Dave Jones]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/