Re: mm: mmap_sem lock assertion failure in __mlock_vma_pages_range

[Sasha Levin]

On 03/11/2014 04:07 PM, Davidlohr Bueso wrote:

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(&current->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(&current->mm->mmap_sem);

Yeah, this patch doesn't look like it's causing it, I guess it was more of a 
"you touched this
code last - do you still remember what's going on here?" :).

It's semi-odd because it seems like an obvious issue to hit with trinity but 
it's the first time
I've seen it and it's probably been there for a while (that BUG_ON is there 
from 2009).


Thanks,
Sasha
--
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/