Re: mm: BUG in unmap_page_range

[Hugh Dickins]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/