All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Frank van Maarseveen <frankvm@frankvm.com>,
	"Mr. Charles Edward Lever" <Chuck.Lever@oracle.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Linux NFS mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [NLM] 2.6.27.14 breakage when grace period expires
Date: Fri, 13 Feb 2009 12:04:55 +0100	[thread overview]
Message-ID: <20090213110455.GA19939@janus> (raw)
In-Reply-To: <1234470251.7190.102.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>

On Thu, Feb 12, 2009 at 03:24:11PM -0500, Trond Myklebust wrote:
> 
> Hmm... I wonder if the problem isn't just that we're failing to cancel
> the lock request when the process is signalled. Can you try the
> following patch?
> 
> --------------------------------------------------------------------
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> NLM/lockd: Always cancel blocked locks when exiting early from nlmclnt_lock
> 
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
> 
>  fs/lockd/clntproc.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
> index 31668b6..f956d1e 100644
> --- a/fs/lockd/clntproc.c
> +++ b/fs/lockd/clntproc.c
> @@ -542,9 +542,14 @@ again:
>  		status = nlmclnt_call(cred, req, NLMPROC_LOCK);
>  		if (status < 0)
>  			break;
> -		/* Did a reclaimer thread notify us of a server reboot? */
> -		if (resp->status ==  nlm_lck_denied_grace_period)
> +		/* Is the server in a grace period state?
> +		 * If so, we need to reset the resp->status, and
> +		 * retry...
> +		 */
> +		if (resp->status ==  nlm_lck_denied_grace_period) {
> +			resp->status = nlm_lck_blocked;
>  			continue;
> +		}
>  		if (resp->status != nlm_lck_blocked)
>  			break;
>  		/* Wait on an NLM blocking lock */

Patch tried but didn't make any difference. Note that there isn't any ^C
or any other signal involved. The client runs three loops in the shell

	while :; do lck -w /mnt/locktest 2; done

and every "lck" opens the file, obtains an exclusive write lock (waits
if necessary), calls sleep(2), closes the fd (releasing the lock) and
goes exit.

The "lck" which ends up unlocking during grace terminates normally but
one of the others gets a "fcntl: No locks available" when trying to
obtain the lock.


Question: shouldn't the server drop the lock after a sequence like:

201 122.033767  server:  NLM  V4 GRANTED_MSG Call (Reply In 202) FH:0xcafa61cc svid:116 pos:0-0
202 122.034066  client:  NLM  V4 GRANTED_MSG Reply (Call In 201)
205 122.034665  client:  NLM  V4 GRANTED_RES Call (Reply In 206) NLM_DENIED
206 122.034753  server:  NLM  V4 GRANTED_RES Reply (Call In 205)

?

-- 
Frank

  parent reply	other threads:[~2009-02-13 11:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 11:23 [NLM] 2.6.27.14 breakage when grace period expires Frank van Maarseveen
2009-02-11 20:35 ` J. Bruce Fields
2009-02-11 20:37   ` Frank van Maarseveen
2009-02-11 20:39     ` J. Bruce Fields
2009-02-11 20:57       ` Frank van Maarseveen
2009-02-12 14:28       ` Frank van Maarseveen
2009-02-12 15:16         ` Trond Myklebust
     [not found]           ` <1234451789.7190.38.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 15:36             ` Frank van Maarseveen
2009-02-12 18:17               ` Trond Myklebust
     [not found]                 ` <1234462647.7190.53.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 18:29                   ` Frank van Maarseveen
2009-02-12 19:10                     ` Trond Myklebust
     [not found]                       ` <1234465837.7190.62.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 19:16                         ` Frank van Maarseveen
2009-02-12 20:24                           ` Trond Myklebust
     [not found]                             ` <1234470251.7190.102.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-13 11:04                               ` Frank van Maarseveen [this message]
2009-02-12 19:35                         ` Chuck Lever
2009-02-12 19:43                           ` Trond Myklebust
     [not found]                             ` <1234467795.7190.70.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 20:11                               ` Chuck Lever
2009-02-12 20:27                                 ` Trond Myklebust
     [not found]                                   ` <1234470457.7190.106.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 20:43                                     ` Chuck Lever
2009-02-12 20:54                                       ` Trond Myklebust
     [not found]                                         ` <1234472083.7190.124.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 21:43                                           ` Chuck Lever
2009-02-12 22:03                                             ` Trond Myklebust
2009-02-12 22:02                                       ` Trond Myklebust
     [not found]                                         ` <1234476134.7190.187.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-12 22:11                                           ` Chuck Lever
2009-02-12 22:19                                             ` 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=20090213110455.GA19939@janus \
    --to=frankvm@frankvm.com \
    --cc=Chuck.Lever@oracle.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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.