linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fu Liankun <fuliankun@cn.fujitsu.com>
To: linux-nfs@vger.kernel.org
Subject: [PATCH] NFSV4 :All lock operations should be sent to the server for resolution
Date: Fri, 14 Jan 2011 14:45:56 +0800	[thread overview]
Message-ID: <4D2FF124.7020500@cn.fujitsu.com> (raw)

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@cn.fujitsu.com>
---
 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


             reply	other threads:[~2011-01-14  6:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14  6:45 Fu Liankun [this message]
2011-01-14 18:16 ` [PATCH] NFSV4 :All lock operations should be sent to the server for resolution J. Bruce Fields
2011-01-14 18:29   ` Trond Myklebust
2011-11-28  6:31     ` Mi Jinlong
2011-11-28 15:42       ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2FF124.7020500@cn.fujitsu.com \
    --to=fuliankun@cn.fujitsu.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).