* [PATCH] fs:remove a no needed mutex_unlock in devtmpfs
@ 2011-07-29 8:34 Wanlong Gao
2011-07-29 9:02 ` Wanlong Gao
2011-07-29 9:03 ` Li Zefan
0 siblings, 2 replies; 4+ messages in thread
From: Wanlong Gao @ 2011-07-29 8:34 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel, Wanlong Gao
According ed75e95de574c99575e5f3e1d9ca59ea8c12a9cb, Al killed the
lookup_create(), this function will return with an mutex locked,
and it called by dev_mkdir() previously. then unlock this mutex
in dev_mkdir(), but when lookup_create() is replaced by kern_path_create(),
no locked mutex returned, so no need to unlock the mutex.
Al, is it right?
Thanks
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/base/devtmpfs.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index b89fffc..5384883 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -157,7 +157,6 @@ static int dev_mkdir(const char *name, mode_t mode)
/* mark as kernel-created inode */
dentry->d_inode->i_private = &thread;
dput(dentry);
- mutex_unlock(&path.dentry->d_inode->i_mutex);
path_put(&path);
return err;
}
--
1.7.6
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] fs:remove a no needed mutex_unlock in devtmpfs
2011-07-29 8:34 [PATCH] fs:remove a no needed mutex_unlock in devtmpfs Wanlong Gao
@ 2011-07-29 9:02 ` Wanlong Gao
2011-07-29 9:03 ` Li Zefan
1 sibling, 0 replies; 4+ messages in thread
From: Wanlong Gao @ 2011-07-29 9:02 UTC (permalink / raw)
To: Wanlong Gao; +Cc: Al Viro, linux-kernel
On 07/29/2011 04:34 PM, Wanlong Gao wrote:
> According ed75e95de574c99575e5f3e1d9ca59ea8c12a9cb, Al killed the
> lookup_create(), this function will return with an mutex locked,
> and it called by dev_mkdir() previously. then unlock this mutex
> in dev_mkdir(), but when lookup_create() is replaced by kern_path_create(),
> no locked mutex returned, so no need to unlock the mutex.
>
> Al, is it right?
> Thanks
Sorry, kern_path_create() also held a mutex, I made a mistake.
Thanks
>
> Signed-off-by: Wanlong Gao<gaowanlong@cn.fujitsu.com>
> ---
> drivers/base/devtmpfs.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
> index b89fffc..5384883 100644
> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -157,7 +157,6 @@ static int dev_mkdir(const char *name, mode_t mode)
> /* mark as kernel-created inode */
> dentry->d_inode->i_private =&thread;
> dput(dentry);
> - mutex_unlock(&path.dentry->d_inode->i_mutex);
> path_put(&path);
> return err;
> }
--
Thanks
Best Regards
Wanlong Gao
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs:remove a no needed mutex_unlock in devtmpfs
2011-07-29 8:34 [PATCH] fs:remove a no needed mutex_unlock in devtmpfs Wanlong Gao
2011-07-29 9:02 ` Wanlong Gao
@ 2011-07-29 9:03 ` Li Zefan
2011-07-29 9:06 ` Wanlong Gao
1 sibling, 1 reply; 4+ messages in thread
From: Li Zefan @ 2011-07-29 9:03 UTC (permalink / raw)
To: Wanlong Gao; +Cc: Al Viro, linux-kernel
Wanlong Gao wrote:
> According ed75e95de574c99575e5f3e1d9ca59ea8c12a9cb, Al killed the
> lookup_create(), this function will return with an mutex locked,
> and it called by dev_mkdir() previously. then unlock this mutex
> in dev_mkdir(), but when lookup_create() is replaced by kern_path_create(),
> no locked mutex returned, so no need to unlock the mutex.
>
> Al, is it right?
no.. kern_path_create() returns with i_mutex held.
> Thanks
>
> Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> ---
> drivers/base/devtmpfs.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
> index b89fffc..5384883 100644
> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -157,7 +157,6 @@ static int dev_mkdir(const char *name, mode_t mode)
> /* mark as kernel-created inode */
> dentry->d_inode->i_private = &thread;
> dput(dentry);
> - mutex_unlock(&path.dentry->d_inode->i_mutex);
> path_put(&path);
> return err;
> }
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs:remove a no needed mutex_unlock in devtmpfs
2011-07-29 9:03 ` Li Zefan
@ 2011-07-29 9:06 ` Wanlong Gao
0 siblings, 0 replies; 4+ messages in thread
From: Wanlong Gao @ 2011-07-29 9:06 UTC (permalink / raw)
To: Li Zefan; +Cc: Al Viro, linux-kernel
On 07/29/2011 05:03 PM, Li Zefan wrote:
> Wanlong Gao wrote:
>> According ed75e95de574c99575e5f3e1d9ca59ea8c12a9cb, Al killed the
>> lookup_create(), this function will return with an mutex locked,
>> and it called by dev_mkdir() previously. then unlock this mutex
>> in dev_mkdir(), but when lookup_create() is replaced by kern_path_create(),
>> no locked mutex returned, so no need to unlock the mutex.
>>
>> Al, is it right?
>
> no.. kern_path_create() returns with i_mutex held.
yeah, I hasn't seen the *return* when *dentry* is gotten successfully.
Sorry for the noise
>
>> Thanks
>>
>> Signed-off-by: Wanlong Gao<gaowanlong@cn.fujitsu.com>
>> ---
>> drivers/base/devtmpfs.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
>> index b89fffc..5384883 100644
>> --- a/drivers/base/devtmpfs.c
>> +++ b/drivers/base/devtmpfs.c
>> @@ -157,7 +157,6 @@ static int dev_mkdir(const char *name, mode_t mode)
>> /* mark as kernel-created inode */
>> dentry->d_inode->i_private =&thread;
>> dput(dentry);
>> - mutex_unlock(&path.dentry->d_inode->i_mutex);
>> path_put(&path);
>> return err;
>> }
>
--
Thanks
Best Regards
Wanlong Gao
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-07-29 9:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-29 8:34 [PATCH] fs:remove a no needed mutex_unlock in devtmpfs Wanlong Gao
2011-07-29 9:02 ` Wanlong Gao
2011-07-29 9:03 ` Li Zefan
2011-07-29 9:06 ` Wanlong Gao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox