Re: [PATCH] Fix NLM reference count panic

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Jan 04, 2008 at 05:48:49PM -0500, Wendy Cheng wrote:
> This fixes the incorrect fclose call inside nlm_traverse_files() where 
> a posix lock could still be held by NFS client. Problem was found in a
> kernel panic inside locks_remove_flock() (fs/locks.c:2034) as part of 
> the fclose call due to NFS-NLM locks still hanging on inode->i_flock list. 
> 
> Also see: http://people.redhat.com/wcheng/Patches/NFS/NLM/001.txt

Next time it'd be best just to include that into the referred-to text
into the message.

>  svcsubs.c |    3 +--
>  1 files changed, 1 insertion(+), 2 deletions(-)
> 
> --- gfs2-nmw/fs/lockd/svcsubs.c	2007-04-10 11:59:09.000000000 -0400
> +++ linux/fs/lockd/svcsubs.c	2007-04-18 10:01:23.000000000 -0400
> @@ -250,8 +250,7 @@ nlm_traverse_files(struct nlm_host *host
>  			mutex_lock(&nlm_file_mutex);
>  			file->f_count--;
>  			/* No more references to this file. Let go of it. */
> -			if (list_empty(&file->f_blocks) && !file->f_locks
> -			 && !file->f_shares && !file->f_count) {
> +			if (!nlm_file_inuse(file)) {
>  				hlist_del(&file->f_list);
>  				nlmsvc_ops->fclose(file->f_file);
>  				kfree(file);

This just replaces the file->f_locks check by a search of the inode's
lock list.

What confuses me here is that the nlm_inspect_file() call just above
already did that search, and set file->f_locks accordingly.  The only
difference is that now we've acquired the nlm_file_mutex.  I don't
understand yet how that makes a difference.

--b.