[lkml]   [2002]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Non-blocking lock requests during the grace period

On second thoughts, I think I wonder if we want to fail F_GETLK while in
the grace period? seems like we won't there it makes sense to hold until
the grace period clears otherwise the client app may think there is
something wrong (note that F_GETLK man page does not provide EAGAIN as
a possible error code).
The case for F_SETLK is different as the result is expected when the lock
is not available due to a previous holder (or, as I want to do it, when the
lock is not available ether by previous holder or grace period).


| | Trond Myklebust |
| | <trond.myklebust@|
| |> |
| | |
| | 11/15/02 09:35 AM|
| | Please respond to|
| | trond.myklebust |
| | |
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc:, |
| Subject: Re: Non-blocking lock requests during the grace period |
| |
| |

> 2.-I also have this part enclosed in the if(resp->status ==
> if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {
> blah blah...
> wait_on_grace:
> if ((proc == NLMPROC_LOCK) &&
> !argp->block)
> return -EAGAIN
> } else {
> ....
> }
> This with the intention to be very specific as to when we want
> the return -EAGAIN to be called.
The above means that you will still block on a F_GETLK query...

In any case, why would we want to return -EAGAIN in one case where
argp->block isn't set, and not in another? If there are cases where we
want to block and where we are not currently setting argp->block (the
only one I can think of might be NLMPROC_UNLOCK), then we should fix
the caller.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:31    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean