Re: Huge race in lockd for async lock requests?

Rob Gardner
2009-05-28T21:34:19Z

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