Re: [PATCH 04/21] mm: zap_pte_range dont dirty anon

[Hugh Dickins <hugh@veritas.com>]

On Sun, 25 Sep 2005, Andrew Morton wrote:
> Hugh Dickins <hugh@veritas.com> wrote:
> >
> > zap_pte_range already avoids wasting time to mark_page_accessed on anon
> > pages: it can also skip anon set_page_dirty - the page only needs to be
> > marked dirty if shared with another mm, but that will say pte_dirty too.
> 
> Are you sure about this?

Yeerrrssss, well, I'm never _sure_ about anything,
especially when faced by the question.

> What is the page is (for example) clean swapcache, having been recently
> faulted in.  If this pte indicates that this process has modified the page
> and we don't run set_page_dirty(), the page could be reclaimed and the
> change is lost.

Absolutely.  But either the page is unique to this mm, shared only with
swapcache: in which case we're about to do a free_swap_cache on it (that
may be delayed in actually freeing the swap because of not getting page
lock, presumably because vmscan just got to it, but no matter), and we
don't care at all that the page no longer represents what's on swap disk.

Or, the page is shared with another mm.  But it's an anonymous page
(a private page), so it's shared via fork, and COW applies to it.
copy_one_pte did ptep_set_wrprotect on it, and did not pte_mkclean [*].

So if it's dirty from before the fork, the sharing mm will also have
it marked pte_dirty, which will get propagated through to the page
via that mm, and everything's fine even though we're ignoring the
pte_dirty in this unmapping mm.  Or if it's dirty from after the fork,
well, something's gone very wrong if the page is still shared - unless
it's because there's been a further fork since it was dirtied, in which
case that sibling carries the pte_dirty which guarantees its integrity.

The change would be very wrong for the !PageAnon pages:
but it's right for the PageAnon ones, don't you agree?

> Or what is the page was an anon page resulting from (say) a swapoff, and
> it's shared by two mm's and one has modified it and we drop that dirty pte?

Again, the one which tried to modify it will have got a Copy-On-Write
fault, been given a copy of the page, and the original won't be shared.

> Or <other scenarios>.
> 
> Need more convincing.

Convinced?  I hope it's just that you forgot something and now remember.
But do demand more from me if not (and don't feel obliged to devise more
cases to ask about, though they do help - thanks).  Or just drop the
patch, it was merely a passing observation - I'm not building any
great edifice upon it in later patches!

Hugh

[*]  This ignores the issue of the "Linus" pages, those anonymous
pages which have got into a shared vma by ptrace writing while the
vma was unwritable - copy_one_pte's tests are on VM_SHARED.  They're
in a limbo between private and shared, and may indeed behave oddly.
For the moment we'll continue to ignore the oddities of that case.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/