Re: [rfc][patch] mm: dirty page accounting hole

Peter Zijlstra
2008-08-12T11:30:56Z

On Tue, 2008-08-12 at 12:15 +0100, Hugh Dickins wrote:
> On Tue, 12 Aug 2008, Nick Piggin wrote:
> >
> > I think I'm running into a hole in dirty page accounting...
> >
> > What seems to be happening is that a page gets written to via a
> > VM_SHARED vma. We then set the pte dirty, then mark the page dirty.
> > Next, mprotect changes the vma so it is no longer writeable so it
> > is no longer VM_SHARED. The pte is still dirty.
>
> I don't think you've got that right yet.
>
> mprotect can of course change vma->vm_flags to take VM_WRITE off,
> making vma no longer writeable; but it shouldn't be touching
> VM_SHARED. And a quick check with debugger confirms that.
>
> It's precisely because of mprotect that page_mkclean_one tests
> VM_SHARED not VM_WRITE. Changing that to VM_MAYSHARE, as in your
> patch below, should make no difference to correctness; but would
> potentially make its loop less efficient (it would also go off to
> check MAP_SHARED, PROT_READ, fd readonly mappings unnecessarily).
>
> Perhaps there's somewhere else that clears VM_SHARED by mistake?
> Or another path through mprotect which does so? I haven't checked
> further, hoping this will jolt you into a different realization.

You are right, I cannot find a path through mprotect that unsets
VM_SHARED either.

Something which I failed to validate this morning.