[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
>>>>> " " == Michael Eisler <> 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.


--- 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.
- 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
Please read the FAQ at
 \ /
  Last update: 2005-03-22 12:45    [W:0.077 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site