[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 <tipecaml@gmail.com>
> ---
> 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
- Re: [PATCH 3/7] Fix double call to pthread_mutex_unlock in repeat_event()., (continued)