summaryrefslogtreecommitdiff
path: root/fs/namei.c
diff options
context:
space:
mode:
authorArjan van de Ven <arjan@infradead.org>2006-03-23 03:00:33 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-23 07:38:12 -0800
commita11f3a0574a5734db3e5de38922430d005d35118 (patch)
tree2f332f623463c5909dc37d20cbf44421854f775a /fs/namei.c
parent144efe3e3e5ad57af549bf800fa4560d7c74e9fe (diff)
[PATCH] sem2mutex: vfs_rename_mutex
Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/namei.c')
-rw-r--r--fs/namei.c12
1 files changed, 6 insertions, 6 deletions
diff --git a/fs/namei.c b/fs/namei.c
index 8dc2b038d5d9..c72b940797fc 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -104,7 +104,7 @@
*/
/*
* [Sep 2001 AV] Single-semaphore locking scheme (kudos to David Holland)
- * implemented. Let's see if raised priority of ->s_vfs_rename_sem gives
+ * implemented. Let's see if raised priority of ->s_vfs_rename_mutex gives
* any extra contention...
*/
@@ -1422,7 +1422,7 @@ struct dentry *lock_rename(struct dentry *p1, struct dentry *p2)
return NULL;
}
- down(&p1->d_inode->i_sb->s_vfs_rename_sem);
+ mutex_lock(&p1->d_inode->i_sb->s_vfs_rename_mutex);
for (p = p1; p->d_parent != p; p = p->d_parent) {
if (p->d_parent == p2) {
@@ -1450,7 +1450,7 @@ void unlock_rename(struct dentry *p1, struct dentry *p2)
mutex_unlock(&p1->d_inode->i_mutex);
if (p1 != p2) {
mutex_unlock(&p2->d_inode->i_mutex);
- up(&p1->d_inode->i_sb->s_vfs_rename_sem);
+ mutex_unlock(&p1->d_inode->i_sb->s_vfs_rename_mutex);
}
}
@@ -2277,17 +2277,17 @@ asmlinkage long sys_link(const char __user *oldname, const char __user *newname)
* a) we can get into loop creation. Check is done in is_subdir().
* b) race potential - two innocent renames can create a loop together.
* That's where 4.4 screws up. Current fix: serialization on
- * sb->s_vfs_rename_sem. We might be more accurate, but that's another
+ * sb->s_vfs_rename_mutex. We might be more accurate, but that's another
* story.
* c) we have to lock _three_ objects - parents and victim (if it exists).
* And that - after we got ->i_mutex on parents (until then we don't know
* whether the target exists). Solution: try to be smart with locking
* order for inodes. We rely on the fact that tree topology may change
- * only under ->s_vfs_rename_sem _and_ that parent of the object we
+ * only under ->s_vfs_rename_mutex _and_ that parent of the object we
* move will be locked. Thus we can rank directories by the tree
* (ancestors first) and rank all non-directories after them.
* That works since everybody except rename does "lock parent, lookup,
- * lock child" and rename is under ->s_vfs_rename_sem.
+ * lock child" and rename is under ->s_vfs_rename_mutex.
* HOWEVER, it relies on the assumption that any object with ->lookup()
* has no more than 1 dentry. If "hybrid" objects will ever appear,
* we'd better make sure that there's no link(2) for them.