On Tue, 8 Apr 2014, Bob Liu wrote: > On Sat, Apr 5, 2014 at 5:04 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > On Mon, 31 Mar 2014, Bob Liu wrote: > > > >> VM_BUG_ON_PAGE(PageActive(page) && PageUnevictable(page), page) in > >> lru_cache_add() was triggered during migrate_misplaced_transhuge_page. > >>... > >> From vmscan.c: > >> * Reasons page might not be evictable: > >> * (1) page's mapping marked unevictable > >> * (2) page is part of an mlocked VMA > >> > >> But page_add_new_anon_rmap() only checks reason (2), we may hit this > >> VM_BUG_ON_PAGE() if PageUnevictable(old_page) was originally set by reason (1). > > > > But (1) always reports evictable on an anon page, doesn't it? > > > >> > >> Reported-by: Sasha Levin <sasha.levin@xxxxxxxxxx> > >> Signed-off-by: Bob Liu <bob.liu@xxxxxxxxxx> > > > > I can't quite assert NAK, but I suspect this is not the proper fix. ... > > > > (Yet now I'm wavering again: if down_write mmap_sem is needed to > > munlock() the vma, and migrate_misplaced_transhuge_page() is only > > migrating a singly-mapped THP under down_read mmap_sem, how could > > VM_LOCKED have changed during the migration? I've lost sight of > > I think you are right, I'll do more investigation about why this BUG > was triggered. Andrew, if Bob agrees, please drop mm-rmap-dont-try-to-add-an-unevictable-page-to-lru-list.patch from mmotm now. We have not heard any such report yet on 3.15-rc, and neither Bob nor I have yet come up with a convincing explanation for how it came about. It's tempting to suppose it was a side-effect of something temporarily wrong on a 3.14-next, and now okay; but we'll learn more quickly whether that's so if mmotm stops working around it. Thanks, Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>