All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Gardner <rob.gardner@hp.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Huge race in lockd for async lock requests?
Date: Wed, 20 May 2009 00:55:47 -0600	[thread overview]
Message-ID: <4A13A973.4050703@hp.com> (raw)
In-Reply-To: <4A1319F9.90304@hp.com>

Tom Talpey wrote:
> At 04:43 PM 5/19/2009, Rob Gardner wrote:
> >I've got a question about lockd in conjunction with a filesystem that 
> >provides its own (async) locking.
> >
> >After nlmsvc_lock() calls vfs_lock_file(), it seems to be that we might 
> >get the async callback (nlmsvc_grant_deferred) at any time. What's to 
> >stop it from arriving before we even put the block on the nlm_block 
> >list? If this happens, then nlmsvc_grant_deferred() will print "grant 
> >for unknown block" and then we'll wait forever for a grant that will 
> >never come.
>
> Yes, there's a race but the client will retry every 30 seconds, so it won't
> wait forever.
OK, a blocking lock request will get retried in 30 seconds and work out 
"ok". But a non-blocking request will get in big trouble. Let's say the 
callback is invoked immediately after the vfs_lock_file call returns 
FILE_LOCK_DEFERRED. At this point, the block is not on the nlm_block 
list, so the callback routine will not be able to find it and mark it as 
granted. Then nlmsvc_lock() will call nlmsvc_defer_lock_rqst(), put the 
block on the nlm_block list, and eventually the request will timeout and 
the client will get lck_denied. Meanwhile, the lock has actually been 
granted, but nobody knows about it.

>  Depending on the kernel client version, there are some
> improvements we've tried over time to close the raciness a little. What
> exact client version are you working with?
>   

I maintain nfs/nlm server code for a NAS product, and so there is no 
"exact client" but rather a multitude of clients that I have no control 
over. All I can do is hack the server. We have been working around this 
by using a semaphore to cover the vfs_lock_file() to 
nlmsvc_insert_block() sequence in nlmsvc_lock() and also 
nlmsvc_grant_deferred(). So if the callback arrives at a bad time, it 
has to wait until the lock actually makes it onto the nlm_block list, 
and so the status of the lock gets updated properly.

> Use NFSv4? ;-)
>   

I had a feeling you were going to say that. ;-)  Unfortunately that 
doesn't make NFSv3 and lockd go away.


Rob Gardner






  parent reply	other threads:[~2009-05-20  6:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 14:48 Virtual IPs and blocking locks Sachin S. Prabhu
2009-05-15 16:50 ` Rob Gardner
2009-05-18 13:41   ` Sachin S. Prabhu
2009-05-18 13:46     ` Trond Myklebust
2009-05-18 13:55     ` Rob Gardner
2009-05-19 20:43       ` Huge race in lockd for async lock requests? Rob Gardner
2009-05-19 21:33         ` Tom Talpey
2009-05-20  6:55         ` Rob Gardner [this message]
2009-05-20 14:00           ` Tom Talpey
     [not found]             ` <4a140d0a.85c2f10a.53bc.0979-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 14:14               ` Tom Talpey
     [not found]                 ` <4a14106e.48c3f10a.7ce3.0e55-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 23:20                   ` Rob Gardner
2009-05-20 16:37               ` Rob Gardner
2009-05-28 20:05                 ` J. Bruce Fields
2009-05-28 21:34                   ` Rob Gardner
2009-05-29  0:26                     ` J. Bruce Fields
2009-05-29  2:59                       ` Rob Gardner
2009-05-29 13:22                         ` Tom Talpey
     [not found]                           ` <4a1fe1c0.06045a0a.165b.5fbc-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-29 15:24                             ` Rob Gardner
2009-05-29 19:14                               ` 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=4A13A973.4050703@hp.com \
    --to=rob.gardner@hp.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 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.