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

[Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>]

On Fri, Apr 24, 2009 at 09:15:22AM +0200, Miklos Szeredi wrote:
> 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

I am not sure how you came to this conclusion.  The address_space has
the vma's chained together and protected by the i_mmap_lock.  That is
acquired prior to the cleaning operation.  Additionally, the cleaning
operation walks the process's page tables and will remove/write-protect
the page before releasing the i_mmap_lock.

Maybe I misunderstand.  I hope I have not added confusion.

Thanks,
Robin
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html