> On Fri, 2008-01-18 at 10:51 +0100, Miklos Szeredi wrote:
quoted text
> 
> > > diff --git a/mm/msync.c b/mm/msync.c
> > > index a4de868..a49af28 100644
> > > --- a/mm/msync.c
> > > +++ b/mm/msync.c
> > > @@ -13,11 +13,33 @@
> > >  #include <linux/syscalls.h>
> > >  
> > >  /*
> > > + * Scan the PTEs for pages belonging to the VMA and mark them read-only.
> > > + * It will force a pagefault on the next write access.
> > > + */
> > > +static void vma_wrprotect(struct vm_area_struct *vma)
> > > +{
> > > +	unsigned long addr;
> > > +
> > > +	for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) {
> > > +		spinlock_t *ptl;
> > > +		pgd_t *pgd = pgd_offset(vma->vm_mm, addr);
> > > +		pud_t *pud = pud_offset(pgd, addr);
> > > +		pmd_t *pmd = pmd_offset(pud, addr);
> > > +		pte_t *pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> > > +
> > > +		if (pte_dirty(*pte) && pte_write(*pte))
> > > +			*pte = pte_wrprotect(*pte);
> > > +		pte_unmap_unlock(pte, ptl);
> > > +	}
> > > +}
> > 
> > What about ram based filesystems?  They don't start out with read-only
> > pte's, so I think they don't want them read-protected now either.
> > Unless this is essential for correct mtime/ctime accounting on these
> > filesystems (I don't think it really is).  But then the mapping should
> > start out read-only as well, otherwise the time update will only work
> > after an msync(MS_ASYNC).
> 
> page_mkclean() has all the needed logic for this, it also walks the rmap
> and cleans out all other users, which I think is needed too for
> consistencies sake:
> 
> Process A			Process B
> 
> mmap(foo.txt)			mmap(foo.txt)
> 
> dirty page
> 				dirty page
> 
> msync(MS_ASYNC)
> 
> 				dirty page
> 
> msync(MS_ASYNC) <--- now what?!

Nothing.  I think it's perfectly acceptable behavior, if msync in
process A doesn't care about any dirtying in process B.

quoted text
> All in all, that sounds rather expensive..

Right.  The advantage of Anton's current approach, is that it's at
least simple, and possibly not so expensive, while providing same
quite sane semantics for MS_ASYNC vs. mtime updates.

Miklos
--
unsubscribe notice
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/