On Tue, 9 Sep 2014, Sasha Levin wrote: > On 09/09/2014 05:33 PM, Mel Gorman wrote: > > On Mon, Sep 08, 2014 at 01:56:55PM -0400, Sasha Levin wrote: > >> On 09/08/2014 01:18 PM, Mel Gorman wrote: > >>> A worse possibility is that somehow the lock is getting corrupted but > >>> that's also a tough sell considering that the locks should be allocated > >>> from a dedicated cache. I guess I could try breaking that to allocate > >>> one page per lock so DEBUG_PAGEALLOC triggers but I'm not very > >>> optimistic. > >> > >> I did see ptl corruption couple days ago: > >> > >> https://lkml.org/lkml/2014/9/4/599 > >> > >> Could this be related? > >> > > > > Possibly although the likely explanation then would be that there is > > just general corruption coming from somewhere. Even using your config > > and applying a patch to make linux-next boot (already in Tejun's tree) > > I was unable to reproduce the problem after running for several hours. I > > had to run trinity on tmpfs as ext4 and xfs blew up almost immediately > > so I have a few questions. > > I agree it could be a case of random corruption somewhere else, it's just > that the amount of times this exact issue reproduced Yes, I doubt it's random corruption; but I've been no more successful than Mel in working it out (I share responsibility for that VM_BUG_ON). Sasha, you say you're getting plenty of these now, but I've only seen the dump for one of them, on Aug26: please post a few more dumps, so that we can look for commonality. And please attach a disassembly of change_protection_range() (noting which of the dumps it corresponds to, in case it has changed around): "Code" just shows a cluster of ud2s for the unlikely bugs at end of the function, we cannot tell at all what should be in the registers by then. I've been rather assuming that the 9d340902 seen in many of the registers in that Aug26 dump is the pte val in question: that's SOFT_DIRTY|PROTNONE|RW. I think RW on PROTNONE is unusual but not impossible (migration entry replacement racing with mprotect setting PROT_NONE, after it's updated vm_page_prot, before it's reached the page table). But exciting though that line of thought is, I cannot actually bring it to a pte_mknuma bug, or any bug at all. Mel, no way can it be the cause of this bug - unless Sasha's later traces actually show a different stack - but I don't see the call to change_prot_numa() from queue_pages_range() sharing the same avoidance of PROT_NONE that task_numa_work() has (though it does have an outdated comment about PROT_NONE which should be removed). So I think that site probably does need PROT_NONE checking added. 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>