On Tue, 2014-03-11 at 15:39 -0400, Sasha Levin wrote:
Hi all,
I've ended up deleting the log file by mistake, but this bug does seem to be important
so I'd rather not wait before the same issue is triggered again.
The call chain is:
mlock (mm/mlock.c:745)
__mm_populate (mm/mlock.c:700)
__mlock_vma_pages_range (mm/mlock.c:229)
VM_BUG_ON(!rwsem_is_locked(&mm->mmap_sem));
So __mm_populate() is only called by mlock(2) and this VM_BUG_ON seems
wrong as we call it without the lock held:
up_write(¤t->mm->mmap_sem);
if (!error)
error = __mm_populate(start, len, 0);
return error;
}
It seems to be a rather simple trace triggered from userspace. The only recent patch
in the area (that I've noticed) was "mm/mlock: prepare params outside critical region".
I've reverted it and trying to testing without it.
Odd, this patch should definitely *not* cause this. In any case every
operation removed from the critical region is local to the function:
lock_limit = rlimit(RLIMIT_MEMLOCK);
lock_limit >>= PAGE_SHIFT;
locked = len >> PAGE_SHIFT;
down_write(¤t->mm->mmap_sem);