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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Dave Young
Date: Sunday, April 27, 2008 - 7:10 pm

[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@gmail.com>

---
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)
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 2/2] loop : Don't hold the lo_ctl_mutex while fput ..., Dave Young, (Sun Apr 27, 7:10 pm)