On 01/03/2014 09:52 PM, Linus Torvalds wrote: > On Fri, Jan 3, 2014 at 12:17 PM, Sasha Levin <sasha.le...@oracle.com> wrote: >> >> Ping? This BUG() is triggerable in 3.13-rc6 right now. > > So Andrew suggested just removing the BUG_ON(), but it's been there > for a *long* time.
Yes, Andrew also merged this patch for that: http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-bug_on-from-mlock_vma_page.patch But there wasn't enough confidence in the fix to sent it to you yet, I guess. The related thread: http://www.spinics.net/lists/linux-mm/msg66972.html > And I detest the patch that was sent out that said "Should I check?" > > Maybe we should just remove that mlock_vma_page() thing instead in You mean that it it's already undeterministic because it can be already skipped when mmap_sem can't be acquired for read? I think the assumption for this case is that mmap_sem is already held for write which means VM_LOCKED is unset anyway (per comments at try_to_unmap_file(), which calls try_to_unmap_cluster()). I'm however not sure how it is protected from somebody else holding the semaphore... > try_to_unmap_cluster()? Or maybe actually lock the page around calling > it? check_page is already locked, see try_to_munlock() which calls try_to_unmap_file(). So this might smell of potential deadlock? I'm for going with the removal of BUG_ON. The TestSetPageMlocked should provide enough race protection. > Linus > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"d...@kvack.org";> em...@kvack.org </a> > -- 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/
