>>>>> " " == Michael Eisler <mre@Zambeel.com> writes:
> The fix still does not provide coherency guarantees in all
> situations, and at minimum, there ought to be a way to force
> the client provide a coherency guarantee.
Yes. I came to the same conclusion after having sent it off. I hope
the following patch is more acceptable.
This will always invalidate the page cache whenever we try to obtain
the lock, hence you are guaranteed that the cache will be reread after
the lock was grabbed.
After unlocking however one needs no guarantees other than ensuring
that any modifications were committed while we held the lock, so we
flush the writebacks, drop the lock, and leave it at that.
Cheers,
Trond
--- linux-2.4.0-test8/fs/nfs/file.c Fri Jun 30 01:02:40 2000
+++ linux-2.4.0-test8-fix_lock/fs/nfs/file.c Fri Sep 15 13:11:39 2000
@@ -291,10 +291,13 @@
status = 0;
/*
- * Make sure we re-validate anything we've got cached.
+ * Make sure we clear the cache whenever we try to get the lock.
* This makes locking act as a cache coherency point.
*/
out_ok:
- NFS_CACHEINV(inode);
+ if ((cmd == F_SETLK || cmd == F_SETLKW) && fl->fl_type != F_UNLCK) {
+ nfs_wb_all(inode); /* we may have slept */
+ nfs_zap_caches(inode);
+ }
return status;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:25 EST