On Tue, 2010-03-16 at 18:20 +0800, Mi Jinlong wrote:
>
> Trond Myklebust 写道:
> > On Fri, 2010-03-12 at 18:17 +0800, Mi Jinlong wrote:
> >> If local reason cause nfslock request send fail(means status < 0,
> >> resp->status not be reset), the request will be process as blocked
> >> at first now.
> >>
> >> This patch initialize resp->status to nlm_lck_denied_nolocks, it
> >> can make the following process correctly.
> >>
> >> Signed-off-by: Mi Jinlong <mijinlong@xxxxxxxxxxxxxx>
> >> ---
> >> fs/lockd/clntproc.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
> >> index c81249f..a631582 100644
> >> --- a/fs/lockd/clntproc.c
> >> +++ b/fs/lockd/clntproc.c
> >> @@ -535,7 +535,7 @@ again:
> >> * Initialise resp->status to a valid non-zero value,
> >> * since 0 == nlm_lck_granted
> >> */
> >> - resp->status = nlm_lck_blocked;
> >> + resp->status = nlm_lck_denied_nolocks;
> >> for(;;) {
> >> /* Reboot protection */
> >> fl->fl_u.nfs_fl.state = host->h_state;
> >
> > We _want_ to process it as being blocked if the RPC call was
> > interrupted. The above patch will cause the client to just abandon the
> > interrupted lock request without sending the CANCEL request...
>
> No, the above patch don't just abandon the interrupted lock request,
> when the RPC call was interrupted, client will send an UNLOCK request for status < 0.
> ...
> 583 if (status < 0)
> 584 goto out_unlock;
> ...
>
> And, I think an UNLOCK request is more advisable than a CANCEL request.
> If a LOCK request was succeed when CANCEL request coming, it's useless;
> the lock should be unlocked.
An unlock does not guarantee that the server will cancel the blocked
lock request.
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
