[PATCH 2/2] loop : Don't hold the lo_ctl_mutex while fput inloop_clr_fd

[Dave Young]

[Fixing bug 10504]

If the bakingfile is a block device file, losetuo -d will trigger lockdep
warning of "circular locking dependency".

open/release lock order : bdev->bd_mutex ---> lo->lo_ctl_mutex
loop_clr_fd lock order  : lo->lo_ctl_mutex ---> bdev->bd_mutex (fput)

Don't hold the lo_ctl_mutex while fput in loop_clr_fd to fix it. It's safe
because all loop device state will be consistent here.

Signed-off-by: Dave Young <hidave.darkstar@xxxxxxxxx>

---
drivers/block/loop.c |    5 +++++
1 file changed, 5 insertions(+)

diff -upr linux/drivers/block/loop.c linux.new/drivers/block/loop.c
--- linux/drivers/block/loop.c	2008-04-25 10:10:25.000000000 +0800
+++ linux.new/drivers/block/loop.c	2008-04-25 10:10:35.000000000 +0800
@@ -923,7 +923,12 @@ static int loop_clr_fd(struct loop_devic
 	bd_set_size(bdev, 0);
 	mapping_set_gfp_mask(filp->f_mapping, gfp);
 	lo->lo_state = Lo_unbound;
+
+	/* unlock the lo_ctl_mutex to silence lockdep in case
+	 the backingfile is a block device */
+	mutex_unlock(&lo->lo_ctl_mutex);
 	fput(filp);
+	mutex_lock(&lo->lo_ctl_mutex);
 	/* This is safe: open() is still holding a reference. */
 	module_put(THIS_MODULE);
 	if (max_part > 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/