[PATCH] lockd: release reference to nsm_handle in nlm_host_rebooted

[PATCH] lockd: release reference to nsm_handle in nlm_host_rebooted

[Jeff Layton]

nsm_reboot_lookup takes a reference to the nsm_handle that it returns,
but nlm_host_rebooted never releases that reference.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/lockd/host.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 4600c20..bb464d1 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -479,8 +479,8 @@ again:	mutex_lock(&nlm_host_mutex);
 			}
 		}
 	}
-
 	mutex_unlock(&nlm_host_mutex);
+	nsm_release(nsm);
 }
 
 /*
-- 
1.6.6

Re: [PATCH] lockd: release reference to nsm_handle in nlm_host_rebooted

[J. Bruce Fields]

On Fri, Feb 05, 2010 at 03:09:12PM -0500, Jeff Layton wrote:
> nsm_reboot_lookup takes a reference to the nsm_handle that it returns,
> but nlm_host_rebooted never releases that reference.

Makes sense to me; I'll apply to the nfsd tree.

(How did you run across this?)

--b.

> 
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  fs/lockd/host.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/lockd/host.c b/fs/lockd/host.c
> index 4600c20..bb464d1 100644
> --- a/fs/lockd/host.c
> +++ b/fs/lockd/host.c
> @@ -479,8 +479,8 @@ again:	mutex_lock(&nlm_host_mutex);
>  			}
>  		}
>  	}
> -
>  	mutex_unlock(&nlm_host_mutex);
> +	nsm_release(nsm);
>  }
>  
>  /*
> -- 
> 1.6.6
> 

Re: [PATCH] lockd: release reference to nsm_handle in nlm_host_rebooted

[Jeff Layton]

On Mon, 8 Feb 2010 16:19:08 -0500
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Fri, Feb 05, 2010 at 03:09:12PM -0500, Jeff Layton wrote:
> > nsm_reboot_lookup takes a reference to the nsm_handle that it returns,
> > but nlm_host_rebooted never releases that reference.
> 
> Makes sense to me; I'll apply to the nfsd tree.
> 
> (How did you run across this?)
> 
> --b.
> 

Thanks,

When I was testing Chuck's statd patches, I went through some rather
strange scenarios, mostly with Linux as the client. In some cases, we
noticed that an SM_UNMON would occur when umounting a NFS filesystem,
and in others it wouldn't. These two patches are the result of tracking
down the cause. With them in place, a SM_UNMON gets issued much more
consistently in the face of server reboots.

Cheers,
-- 
Jeff Layton <jlayton@redhat.com>