bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 6/7] Fix double call to pthread_mutex_unlock in diskfs_rename


From: Samuel Thibault
Subject: Re: [PATCH 6/7] Fix double call to pthread_mutex_unlock in diskfs_rename_dir().
Date: Mon, 17 Dec 2012 01:41:46 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Cyril Roelandt, le Mon 17 Dec 2012 00:51:29 +0100, a écrit :
> * libdiskfs/dir-renamed.c (diskfs_rename_dir): remove a redundant call to
> pthread_mutex_unlock.
> 
> Signed-off-by: Cyril Roelandt <address@hidden>
> ---
>  libdiskfs/dir-renamed.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libdiskfs/dir-renamed.c b/libdiskfs/dir-renamed.c
> index 3990b13..7829373 100644
> --- a/libdiskfs/dir-renamed.c
> +++ b/libdiskfs/dir-renamed.c
> @@ -228,8 +228,6 @@ diskfs_rename_dir (struct node *fdp, struct node *fnp, 
> const char *fromname,
>      diskfs_nput (tnp);
>    if (fdp && fdp != tdp)
>      pthread_mutex_unlock (&fdp->lock);
> -  if (fnp)
> -    pthread_mutex_unlock (&fnp->lock);

I believe it's not so simple: AIUI, diskfs_lookup actually returns
fnp in tmpnp (see assert (!tmpnp || tmpnp == fnp);), locked, so an
unlock is actually needed. The !tmpnp case however needs to be further
investigated, since in that case fnp would not be locked.  I guess this
testcase could be triggered by running a lot of concurrent renamers for
the same directory.

So nacked, but worth further investigation.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]