All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Linux NFS mailing list <nfs@lists.sourceforge.net>
Subject: [PATCH] lockd: unlock when client rejects GRANTED_MSG
Date: Sun, 1 Jul 2007 16:38:01 +0200	[thread overview]
Message-ID: <20070701143801.GA22967@janus> (raw)
In-Reply-To: <20070629155226.GA25561@janus>


When lockd grants a blocked lock request after a while then the client
response on it should not be ignored: When the client rejects GRANTED_MSG
with GRANTED_RES NLM_LCK_DENIED then lockd on the server must release
the POSIX lock.

Signed-off-by: Frank van Maarseveen <frankvm@frankvm.com>
---

On Fri, Jun 29, 2007 at 05:52:26PM +0200, Frank van Maarseveen wrote:
> Both server and client run 2.6.21.5 and use NFSv3 over UDP.
> 
> The server has a second IP address on eth0. The client mounts from the
> second address. Two instances of attached test program run on the client
> specifying the same lockfile. Basically they repeatedly F_SETLKW for
> an exclusive lock, sleep 0.2s with lock held, unlock, sleep 0.1s. The
> F_SETLKW is aborted by alarm(10) which normally shouldn't happen.
> 
> This works for a minute and then both alarm clocks go off and the file is
> still locked on the server but not on the client. Wireshark NLM traffic:

[snip]

This is basically what happens:

1	Client tries to obtain a lock, server says NLM_BLOCKED and prepares
	to call the client later when the conflicting lock is released.

2	When the conflicting lock is released, the server calls
	nlm_async_call() via which nlm_bind_host() creates a new transport
	with no knowledge about any source IP address to pick.
	A GRANTED_MSG goes out with a source IP address which differs from
	the destination address in the original client request.

3	Client checks IP address in nlmclnt_grant() and rejects it with
	GRANTED_RES NLM_LCK_DENIED.

4	Server ignores the error in nlmsvc_grant_reply(). It always removes
	the block (struct nlm_block) which is correct but forgets to
	remove the POSIX lock itself in case the client rejected the lock.

IMHO #2 is incorrect and #3 is a questionable check (does it buy us
anything?). #4 definately is a bug and is fixed below.

--- a/fs/lockd/svclock.c	2007-05-12 21:28:09.000000000 +0200
+++ b/fs/lockd/svclock.c	2007-07-01 14:51:21.000000000 +0200
@@ -646,20 +646,27 @@
 nlmsvc_grant_reply(struct nlm_cookie *cookie, __be32 status)
 {
 	struct nlm_block	*block;
+	struct nlm_lock		*lock;
+	int			error;
 
 	dprintk("grant_reply: looking for cookie %x, s=%d \n",
 		*(unsigned int *)(cookie->data), status);
 	if (!(block = nlmsvc_find_block(cookie)))
 		return;
 
-	if (block) {
-		if (status == nlm_lck_denied_grace_period) {
-			/* Try again in a couple of seconds */
-			nlmsvc_insert_block(block, 10 * HZ);
-		} else {
-			/* Lock is now held by client, or has been rejected.
-			 * In both cases, the block should be removed. */
-			nlmsvc_unlink_block(block);
+	if (status == nlm_lck_denied_grace_period) {
+		/* Try again in a couple of seconds */
+		nlmsvc_insert_block(block, 10 * HZ);
+	} else {
+		/* Lock is now held by client, or has been rejected.
+		 * In both cases, the block should be removed. */
+		nlmsvc_unlink_block(block);
+
+		if (status == nlm_lck_denied) {
+			lock = &block->b_call->a_args.lock;
+			lock->fl.fl_type = F_UNLCK;
+			error = posix_lock_file(block->b_file->f_file, &lock->fl);
+			dprintk("nlmsvc_grant_reply: posix_lock_file returned %d\n", error);
 		}
 	}
 	nlmsvc_release_block(block);

-- 
Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-07-01 14:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 15:52 NFSv3 locking bugs (trace+testprogram included) Frank van Maarseveen
2007-07-01 14:38 ` Frank van Maarseveen [this message]
2007-07-01 14:58   ` [PATCH] lockd: unlock when client rejects GRANTED_MSG J. Bruce Fields
2007-07-01 15:11     ` Frank van Maarseveen
2007-07-03 20:43       ` J. Bruce Fields
2007-07-03 20:53       ` J. Bruce Fields
2007-07-03 22:24         ` Frank van Maarseveen
2007-07-03 22:30           ` J. Bruce Fields

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=20070701143801.GA22967@janus \
    --to=frankvm@frankvm.com \
    --cc=nfs@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.