Re: [PATCH, RFC] lockd: stop abusing file_lock_list

[Christoph Hellwig <hch@lst.de>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1975 bytes --]

On Wed, Feb 15, 2006 at 11:44:31PM -0500, Trond Myklebust wrote:
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> lockd: Fix Oopses due to list manipulation errors.
> 
> The patch "stop abusing file_lock_list introduces a couple of bugs since
> the locks may be copied and need to be removed from the lists when they are
> destroyed.
> 
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
> 
>  fs/lockd/clntproc.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
> index 211113a..b1b924d 100644
> --- a/fs/lockd/clntproc.c
> +++ b/fs/lockd/clntproc.c
> @@ -447,12 +447,17 @@ static void nlmclnt_locks_copy_lock(stru
>  {
>  	memcpy(&new->fl_u.nfs_fl, &fl->fl_u.nfs_fl, sizeof(new->fl_u.nfs_fl));
>  	nlm_get_lockowner(new->fl_u.nfs_fl.owner);
> +	INIT_LIST_HEAD(&new->fl_u.nfs_fl.list);
> +	if (!list_empty(&fl->fl_u.nfs_fl.list))
> +		list_add(&new->fl_u.nfs_fl.list, &fl->fl_u.nfs_fl.list);

list_add initializes ænough so we don't need the INIT_LIST_HEAD in that
case, so this could become:

	if (list_empty(&fl->fl_u.nfs_fl.list))
		INIT_LIST_HEAD(&new->fl_u.nfs_fl.list);
	else
		list_add(&new->fl_u.nfs_fl.list, &fl->fl_u.nfs_fl.list);

>  	 * Remove from the granted list now so the lock doesn't get
>  	 * reclaimed while we're stuck in the unlock call.
>  	 */
> -	list_del(&fl->fl_u.nfs_fl.list);
> +	if (!list_empty(&fl->fl_u.nfs_fl.list))
> +		list_del_init(&fl->fl_u.nfs_fl.list);

Probably should be just unconditionaly.  list_del_init isn't a whole lot
of instructions, but we save a branch and have more readable code.

While we're at it, don't we need a INIT_LIST_HEAD in
nlmclnt_locks_init_private aswell?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html