The RFC3530 describes that the client's all lock operations, including those
requesting non-exclusive locks, should be sent to the server for resolution,
even if it holds a read open delegation. But the kernel implements like that
lock operations can be performed locally when a client holds an open
delegation.
The following are the RFC3530 provisions for Open Delegation and File Locks:
9.4.2. Open Delegation and File Locks
When a client holds a write open delegation, lock operations may be
performed locally. This includes those required for mandatory file
locking. This can be done since the delegation implies that there
can be no conflicting locks. Similarly, all of the revalidations
that would normally be associated with obtaining locks and the
flushing of data associated with the releasing of locks need not be
done.
When a client holds a read open delegation, lock operations are not
performed locally. All lock operations, including those requesting
non-exclusive locks, are sent to the server for resolution.
Signed-off-by: Fu Liankun <fuliankun@xxxxxxxxxxxxxx>
---
fs/nfs/nfs4proc.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 0f24cdf..3bba85b 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4215,13 +4215,6 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lock
if (status < 0)
goto out;
down_read(&nfsi->rwsem);
- if (test_bit(NFS_DELEGATED_STATE, &state->flags)) {
- /* Yes: cache locks! */
- /* ...but avoid races with delegation recall... */
- request->fl_flags = fl_flags & ~FL_SLEEP;
- status = do_vfs_lock(request->fl_file, request);
- goto out_unlock;
- }
status = _nfs4_do_setlk(state, cmd, request, NFS_LOCK_NEW);
if (status != 0)
goto out_unlock;
--
1.7.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
