The patch titled
Subject: fs/ufs: revert "ufs: fix deadlocks introduced by sb mutex merge"
has been added to the -mm tree. Its filename is
revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Fabian Frederick <fabf@xxxxxxxxx>
Subject: fs/ufs: revert "ufs: fix deadlocks introduced by sb mutex merge"
This reverts commit 9ef7db7f38d0 ("ufs: fix deadlocks introduced by sb
mutex merge") That patch tried to solve commit 0244756edc4b98c ("ufs: sb
mutex merge + mutex_destroy") which is itself partially reverted due to
multiple deadlocks.
Signed-off-by: Fabian Frederick <fabf@xxxxxxxxx>
Suggested-by: Jan Kara <jack@xxxxxxx>
Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
Cc: Evgeniy Dushistov <dushistov@xxxxxxx>
Cc: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>
Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Cc: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/ufs/inode.c | 5 ++++-
fs/ufs/namei.c | 14 ++++++++------
2 files changed, 12 insertions(+), 7 deletions(-)
diff -puN fs/ufs/inode.c~revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge fs/ufs/inode.c
--- a/fs/ufs/inode.c~revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge
+++ a/fs/ufs/inode.c
@@ -902,6 +902,9 @@ void ufs_evict_inode(struct inode * inod
invalidate_inode_buffers(inode);
clear_inode(inode);
- if (want_delete)
+ if (want_delete) {
+ lock_ufs(inode->i_sb);
ufs_free_inode(inode);
+ unlock_ufs(inode->i_sb);
+ }
}
diff -puN fs/ufs/namei.c~revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge fs/ufs/namei.c
--- a/fs/ufs/namei.c~revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge
+++ a/fs/ufs/namei.c
@@ -128,12 +128,12 @@ static int ufs_symlink (struct inode * d
if (l > sb->s_blocksize)
goto out_notlocked;
+ lock_ufs(dir->i_sb);
inode = ufs_new_inode(dir, S_IFLNK | S_IRWXUGO);
err = PTR_ERR(inode);
if (IS_ERR(inode))
- goto out_notlocked;
+ goto out;
- lock_ufs(dir->i_sb);
if (l > UFS_SB(sb)->s_uspi->s_maxsymlinklen) {
/* slow symlink */
inode->i_op = &ufs_symlink_inode_operations;
@@ -184,9 +184,13 @@ static int ufs_mkdir(struct inode * dir,
struct inode * inode;
int err;
+ lock_ufs(dir->i_sb);
+ inode_inc_link_count(dir);
+
inode = ufs_new_inode(dir, S_IFDIR|mode);
+ err = PTR_ERR(inode);
if (IS_ERR(inode))
- return PTR_ERR(inode);
+ goto out_dir;
inode->i_op = &ufs_dir_inode_operations;
inode->i_fop = &ufs_dir_operations;
@@ -194,9 +198,6 @@ static int ufs_mkdir(struct inode * dir,
inode_inc_link_count(inode);
- lock_ufs(dir->i_sb);
- inode_inc_link_count(dir);
-
err = ufs_make_empty(inode, dir);
if (err)
goto out_fail;
@@ -215,6 +216,7 @@ out_fail:
inode_dec_link_count(inode);
unlock_new_inode(inode);
iput (inode);
+out_dir:
inode_dec_link_count(dir);
unlock_ufs(dir->i_sb);
goto out;
_
Patches currently in -mm which might be from fabf@xxxxxxxxx are
configfs-unexport-make-static-config_item_init.patch
fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch
fs-befs-btreec-remove-unneeded-initializations.patch
revert-ufs-fix-deadlocks-introduced-by-sb-mutex-merge.patch
ufs-restore-s_lock-mutex.patch
fs-affs-inodec-remove-unneeded-initialization.patch
fs-affs-amigaffsc-remove-unneeded-initialization.patch
fs-affs-symlinkc-remove-unneeded-err-variable.patch
linux-next.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
