> 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.
Miklos
----
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/
