> 2.6.38-stable review patch. If anyone has any objections, please let us know. > > ------------------ > > From: J. Bruce Fields <[email protected]> > > commit 23fcf2ec93fb8573a653408316af599939ff9a8e upstream. > > Lock stateid's can have access_bmap 0 if they were only partially > initialized (due to a failed lock request); handle that case in > free_generic_stateid.
I'm looking filp leak on recent kernel. Well, anyway, 23fcf2ec93fb8573a653408316af599939ff9a8e is strange, and I think it can be one of causes. [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 <[email protected]> --- 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 <[email protected]> _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
