On Sun, Apr 17, 2011 at 8:03 AM, OGAWA Hirofumi
<hirofumi@xxxxxxxxxxxxxxxxxx> wrote:
>
> I'm looking filp leak on recent kernel. Well, anyway,
> 23fcf2ec93fb8573a653408316af599939ff9a8e is strange, and I think it can
> be one of causes.
Hmm. Your patch looks correct to me. Added Neil and linux-nfs.
Bruce? Neil?
Linus
---
> [PATCH] nfsd4: Fix filp leak
>
> 23fcf2ec93fb8573a653408316af599939ff9a8e (nfsd4: fix oops on lock failure)
>
> The above patch breaks free path for stp->st_file. If stp was inserted
> into sop->so_stateids, we have to free stp->st_file refcount. Because
> stp->st_file refcount itself is taken unrelated to stp->st_file->fi_fds[].
>
> Signed-off-by: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
> ---
>
> fs/nfsd/nfs4state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN fs/nfsd/nfs4state.c~nfsd4-filp-leak-fix fs/nfsd/nfs4state.c
> --- linux-2.6/fs/nfsd/nfs4state.c~nfsd4-filp-leak-fix 2011-04-17 20:45:45.000000000 +0900
> +++ linux-2.6-hirofumi/fs/nfsd/nfs4state.c 2011-04-17 20:59:53.000000000 +0900
> @@ -402,8 +402,8 @@ static void free_generic_stateid(struct
> if (stp->st_access_bmap) {
> oflag = nfs4_access_bmap_to_omode(stp);
> nfs4_file_put_access(stp->st_file, oflag);
> - put_nfs4_file(stp->st_file);
> }
> + put_nfs4_file(stp->st_file);
> kmem_cache_free(stateid_slab, stp);
> }
>
> _
> --
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
>
--
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
