Re: Why doesn't zap_pte_range() call page_mkwrite()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Apr 2009, Trond Myklebust wrote:
> On Thu, 2009-04-23 at 21:52 +0200, Miklos Szeredi wrote:
> > Now this is mostly done at page fault time, and the pte's are always
> > being re-protected whenever the PG_dirty flag is cleared (see
> > page_mkclean()).
> > 
> > But in some cases (shmfs being the example I know) pages are not write
> > protected and so zap_pte_range(), and other functions, still need to
> > transfer the pte dirtyness to the page flag.
> 
> My main worry is that this is all happening at munmap() time. There
> shouldn't be any more page faults after that completes (am I right?), so
> what other mechanism would transfer the pte dirtyness?

After munmap() a page fault will result in SIGSEGV.  A write access
during munmap(), when the vma has been removed but the page table is
still intact is more interesting.  But in that case the write fault
should also result in a SEGV, because it won't be able to find the
matching VMA.

Now lets see what happens if writeback is started against the page
during this limbo period.  page_mkclean() is called, which doesn't
find the vma, so it doesn't re-protect the pte.  But the PG_dirty will
be cleared regadless.  So AFAICS it can happen that the pte remains
dirty but the page is clean.

And in that case that set_page_dirty() in zap_pte_range() is
important, since the page could have been dirtied through the mapping
after the writeback finished.

> > Not sure how this matters to NFS though.  If the above is correct,
> > then the set_page_dirty() call in zap_pte_range() should always result
> > in a no-op, since the PG_dirty flag would already have been set by the
> > page fault...
> 
> If I can ignore the dirty flag on these occasions, then that would be
> great. That would enable me to get rid of that BUG_ON(PG_CLEAN) in
> write.c, and close the bug...

I don't think you can ignore the dirty flag...  

Hmm, I guess this is a bit nasty: the VM promises filesystems that
->page_mkwrite() will be called when the page is dirtied through a
mapping, _almost_ all of the time.  Except when munmap happens to race
with clear_page_dirty_for_io().

I don't have any ideas how this could be fixed, CC-ing linux-mm...

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux