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
next prev 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.