This patch prevents from deadlock on inode being dropped.
The deadlock is caused by inderect call of mark_inode_dirty()
within udf_drop_inode() but inode lock is already kept
by the kernel. So moving code from udf_drop_inode() to
udf_delete_inode() we save its functionality and avoid
deadlock.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
Andrew the patch is over Jan's two patches you have dropped.
AFAIS a such code moving is quite safe but I'm waiting for
Jan's comments anyway.
fs/udf/inode.c | 20 ++++++++------------
fs/udf/super.c | 1 -
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 9fcd76c..ae56f25 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -83,6 +83,14 @@ static int udf_get_block(struct inode *, sector_t, struct
buffer_head *, int);
*/
void udf_delete_inode(struct inode *inode)
{
+ if (!(inode->i_sb->s_flags & MS_RDONLY)) {
+ lock_kernel();
+ /* Discard preallocation for directories, symlinks, etc. */
+ udf_discard_prealloc(inode);
+ udf_truncate_tail_extent(inode);
+ unlock_kernel();
+ }
+
truncate_inode_pages(&inode->i_data, 0);
if (is_bad_inode(inode))
@@ -102,18 +110,6 @@ no_delete:
clear_inode(inode);
}
-void udf_drop_inode(struct inode *inode)
-{
- if (!(inode->i_sb->s_flags & MS_RDONLY)) {
- lock_kernel();
- /* Discard preallocation for directories, symlinks, etc. */
- udf_discard_prealloc(inode);
- udf_truncate_tail_extent(inode);
- unlock_kernel();
- }
- generic_drop_inode(inode);
-}
-
void udf_clear_inode(struct inode *inode)
{
kfree(UDF_I_DATA(inode));
diff --git a/fs/udf/super.c b/fs/udf/super.c
index b02d2c2..deb0d29 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -166,7 +166,6 @@ static const struct super_operations udf_sb_ops = {
.write_inode = udf_write_inode,
.delete_inode = udf_delete_inode,
.clear_inode = udf_clear_inode,
- .drop_inode = udf_drop_inode,
.put_super = udf_put_super,
.write_super = udf_write_super,
.statfs = udf_statfs,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
