Messages in this thread Patch in this message | | | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> | Date | 15 Sep 2000 15:37:25 +0200 |
| |
>>>>> " " == 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/
| |