On Tue, 2008-01-15 at 21:27 +0100, Miklos Szeredi wrote: > > 1. Introduction > > > > This is the fourth version of my solution for the bug #2645: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=2645 > > > > Changes since the previous version: > > > > 1) the case of retouching an already-dirty page pointed out > > by Miklos Szeredi has been addressed; > > I'm a bit sceptical, as we've also pointed out, that this is not > possible without messing with the page tables. > > Did you try my test program on the patched kernel? > > I've refreshed the patch, where we left this issue last time. It > should basically have equivalent functionality to your patch, and is a > lot simpler. There might be performance issues with it, but it's a > good starting point.
It has the same problem as Anton's in that it won't get triggered again for an already dirty mapped page. But yeah, its simpler than fudging set_page_dirty(). > Index: linux/mm/memory.c > =================================================================== > --- linux.orig/mm/memory.c 2008-01-09 21:16:30.000000000 +0100 > +++ linux/mm/memory.c 2008-01-15 21:16:14.000000000 +0100 > @@ -1680,6 +1680,8 @@ gotten: > unlock: > pte_unmap_unlock(page_table, ptl); > if (dirty_page) { > + if (vma->vm_file) > + file_update_time(vma->vm_file); > /* > * Yes, Virginia, this is actually required to prevent a race > * with clear_page_dirty_for_io() from clearing the page dirty > @@ -2313,6 +2315,8 @@ out_unlocked: > if (anon) > page_cache_release(vmf.page); > else if (dirty_page) { > + if (vma->vm_file) > + file_update_time(vma->vm_file); > set_page_dirty_balance(dirty_page, page_mkwrite); > put_page(dirty_page); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/