Messages in this thread Patch in this message | | | Subject | Re: INFO: task hung in __blkdev_get | From | Tetsuo Handa <> | Date | Tue, 10 Apr 2018 19:55:11 +0900 |
| |
Hello.
Since syzbot is reporting so many hung up bug which involves /dev/loopX , is it possible to "temporarily" apply below patch for testing under syzbot ( after "block/loop: fix deadlock after loop_set_status" and "loop: fix LOOP_GET_STATUS lock imbalance" in linux-block.git#for-linus are merged into linux.git )?
I haven't got a smoking gun by lockdep, but I noticed that
[upstream] INFO: task hung in lo_open (2) https://syzkaller.appspot.com/bug?id=1f93b57f496d969efb9fb24167f6f9de5ee068fd
contained "lo->lo_ctl_mutex => bdev->bd_mutex" locking order
2 locks held by syz-executor6/15084: #0: (&lo->lo_ctl_mutex/1){+.+.}, at: [<00000000cc154b8d>] lo_ioctl+0x8b/0x1b70 drivers/block/loop.c:1355 #1: (&bdev->bd_mutex){+.+.}, at: [<0000000058b7c5b5>] blkdev_reread_part+0x1e/0x40 block/ioctl.c:192
while commit f028f3b2f987ebc6 ("loop: fix circular locking in loop_clr_fd()") says that
* Calling fput holding lo_ctl_mutex triggers a circular * lock dependency possibility warning as fput can take * bd_mutex which is usually taken before lo_ctl_mutex.
which implies that the locking order should be "bdev->bd_mutex => lo->lo_ctl_mutex" and also says that use of "_nested" version might mask some other real bugs which could be the bug syzbot is frequently reporting as hung tasks...
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 264abaa..5559b15 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1360,7 +1360,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode, struct loop_device *lo = bdev->bd_disk->private_data; int err; - err = mutex_lock_killable_nested(&lo->lo_ctl_mutex, 1); + err = mutex_lock_killable(&lo->lo_ctl_mutex); if (err) goto out_unlocked;
| |