Re: [PATCH] Fix bug nfslock request sending fail will be process as blocked

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2010-03-16 at 18:20 +0800, Mi Jinlong wrote:=20
>=20
> Trond Myklebust =E5=86=99=E9=81=93:
> > On Fri, 2010-03-12 at 18:17 +0800, Mi Jinlong wrote:=20
> >> If local reason cause nfslock request send fail(means status < 0,
> >> resp->status not be reset), the request will be process as blocked=
=20
> >> at first now.
> >>
> >> This patch initialize resp->status to nlm_lck_denied_nolocks, it=20
> >> can make the following process correctly.
> >>
> >> Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> >> ---
> >>  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 =3D=3D nlm_lck_granted
> >>  	 */
> >> -	resp->status =3D nlm_lck_blocked;
> >> +	resp->status =3D nlm_lck_denied_nolocks;
> >>  	for(;;) {
> >>  		/* Reboot protection */
> >>  		fl->fl_u.nfs_fl.state =3D host->h_state;
> >=20
> > 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...
>=20
>   No, the above patch don't just abandon the interrupted lock request=
,
>   when the RPC call was interrupted, client will send an UNLOCK reque=
st for status < 0.
>    ...
>    583         if (status < 0)
>    584                 goto out_unlock;
>    ...
>=20
>   And, I think an UNLOCK request is more advisable than a CANCEL requ=
est.
>   If a LOCK request was succeed when CANCEL request coming, it's usel=
ess;
>   the lock should be unlocked.

An unlock does not guarantee that the server will cancel the blocked
lock request.

Trond