All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Gardner <rob.gardner@hp.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "tmtalpey@gmail.com" <tmtalpey@gmail.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Huge race in lockd for async lock requests?
Date: Thu, 28 May 2009 15:34:19 -0600	[thread overview]
Message-ID: <4A1F035B.4040306@hp.com> (raw)
In-Reply-To: <20090528200523.GE13860@fieldses.org>

J. Bruce Fields 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.
>>>>>>     
>> dealing with a filesystem that provides its own locking functions via  
>> file->f_op->lock(). Such a filesystem might easily defer a non-blocking  
>> lock request and invoke the callback later. At least I don't know of any  
>> rule that says that it can't do this, and clearly the code expects this  
>> possibility:
>>
>>              case FILE_LOCK_DEFERRED:
>>                        if (wait)
>>                                break;
>>                        /* Filesystem lock operation is in progress
>>                           Add it to the queue waiting for callback */
>>                        ret = nlmsvc_defer_lock_rqst(rqstp, block);
>>
>>     
>> It looks to me like a bug in the server. The server must be able to deal  
>> with async filesystem callbacks happening at any time, however 
>> inconvenient.
>>     
>
> Absolutely, if that's possible then it's a server bug.
>
> --b.
>   

It's definitely possible for the async filesystem callback to occur at 
any time. I think at the very least, nlmsvc_lock() ought to put the 
block on the nlm_block list *before* calling vfs_lock_file(), and then 
remove it immediately if the lock is granted synchronously. I would like 
to develop and submit a patch for this, but I am currently working with 
a much older kernel and it will take some time before I get to work with 
newer bits.

Rob Gardner


  reply	other threads:[~2009-05-28 21:34 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
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 [this message]
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=4A1F035B.4040306@hp.com \
    --to=rob.gardner@hp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tmtalpey@gmail.com \
    /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.