[PATCH openEuler-1.0-LTS 1/2] block: prevent lockdep false positive warning about 'bd_mutex'

From: Yu Kuai <yukuai3@huawei.com> hulk inclusion category: bugfix bugzilla: 187246, https://gitee.com/openeuler/kernel/issues/I5JQL4 CVE: NA -------------------------------- Commit faf2662e328c ("block: fix that part scan is disabled in device_add_disk()") confuse lockdep to produce following warning: ===================================================== WARNING: possible circular locking dependency detected 4.18.0+ #2 Tainted: G ---------r- - ------------------------------------------------------ syz-executor.0/4652 is trying to acquire lock: 00000000ad5f5a19 (&mddev->open_mutex){+.+.}, at: md_open+0x13a/0x260 home/install/linux-rh-3-10/drivers/md/md.c:7626 but task is already holding lock: 000000005c3a3fea (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x156/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1583 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&bdev->bd_mutex){+.+.}: __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 __blkdev_get+0x156/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1583 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 disk_init_partition home/install/linux-rh-3-10/block/blk-sysfs.c:972 [inline] blk_register_queue+0x5ed/0x6c0 home/install/linux-rh-3-10/block/blk-sysfs.c:1055 __device_add_disk+0xab5/0xd70 home/install/linux-rh-3-10/block/genhd.c:729 sd_probe_async+0x447/0x852 home/install/linux-rh-3-10/drivers/scsi/sd.c:3249 async_run_entry_fn+0xe1/0x700 home/install/linux-rh-3-10/kernel/async.c:127 process_one_work+0x9cf/0x1940 home/install/linux-rh-3-10/kernel/workqueue.c:2175 worker_thread+0x91/0xc50 home/install/linux-rh-3-10/kernel/workqueue.c:2321 kthread+0x33a/0x400 home/install/linux-rh-3-10/kernel/kthread.c:257 ret_from_fork+0x3a/0x50 home/install/linux-rh-3-10/arch/x86/entry/entry_64.S:355 -> #1 (&q->sysfs_dir_lock){+.+.}: __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 blk_register_queue+0x143/0x6c0 home/install/linux-rh-3-10/block/blk-sysfs.c:1010 __device_add_disk+0xab5/0xd70 home/install/linux-rh-3-10/block/genhd.c:729 add_disk home/install/linux-rh-3-10/./include/linux/genhd.h:447 [inline] md_alloc+0xb06/0x10d0 home/install/linux-rh-3-10/drivers/md/md.c:5525 md_probe+0x32/0x60 home/install/linux-rh-3-10/drivers/md/md.c:5554 kobj_lookup+0x2d2/0x450 home/install/linux-rh-3-10/drivers/base/map.c:152 get_gendisk+0x3b/0x360 home/install/linux-rh-3-10/block/genhd.c:860 bdev_get_gendisk home/install/linux-rh-3-10/fs/block_dev.c:1181 [inline] __blkdev_get+0x3b6/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1578 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 blkdev_open+0x1c2/0x250 home/install/linux-rh-3-10/fs/block_dev.c:1923 do_dentry_open+0x686/0xf50 home/install/linux-rh-3-10/fs/open.c:777 do_last home/install/linux-rh-3-10/fs/namei.c:3449 [inline] path_openat+0x92f/0x28c0 home/install/linux-rh-3-10/fs/namei.c:3578 do_filp_open+0x1aa/0x2b0 home/install/linux-rh-3-10/fs/namei.c:3613 do_sys_open+0x307/0x490 home/install/linux-rh-3-10/fs/open.c:1075 do_syscall_64+0xca/0x5c0 home/install/linux-rh-3-10/arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf -> #0 (&mddev->open_mutex){+.+.}: lock_acquire+0x10b/0x3a0 home/install/linux-rh-3-10/kernel/locking/lockdep.c:3868 __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 md_open+0x13a/0x260 home/install/linux-rh-3-10/drivers/md/md.c:7626 __blkdev_get+0x2dc/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1599 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 blkdev_open+0x1c2/0x250 home/install/linux-rh-3-10/fs/block_dev.c:1923 do_dentry_open+0x686/0xf50 home/install/linux-rh-3-10/fs/open.c:777 do_last home/install/linux-rh-3-10/fs/namei.c:3449 [inline] path_openat+0x92f/0x28c0 home/install/linux-rh-3-10/fs/namei.c:3578 do_filp_open+0x1aa/0x2b0 home/install/linux-rh-3-10/fs/namei.c:3613 do_sys_open+0x307/0x490 home/install/linux-rh-3-10/fs/open.c:1075 do_syscall_64+0xca/0x5c0 home/install/linux-rh-3-10/arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf other info that might help us debug this: Chain exists of: &mddev->open_mutex --> &q->sysfs_dir_lock --> &bdev->bd_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&bdev->bd_mutex); lock(&q->sysfs_dir_lock); lock(&bdev->bd_mutex); lock(&mddev->open_mutex); *** DEADLOCK *** Since 'bd_mutex' and 'sysfs_dir_lock' is different is for each device, deadlock between md_open() and sd_probe_async() is impossible. However, lockdep is treating 'bd_mutex' and 'sysfs_dir_lock' from different devices the same, and commit faf2662e328c ("block: fix that part scan is disabled in device_add_disk()") is holding 'bd_mutex' inside 'sysfs_dir_lock', which causes the false positive warning. Fix the false positive warning by don't grab 'bd_mutex' inside 'sysfs_dir_lock'. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> --- block/blk-sysfs.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index ee963759ae10..530f1bf36c87 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -977,10 +977,16 @@ int blk_register_queue(struct gendisk *disk) * before it's registration is done. */ disk->flags |= GENHD_FL_UP; - disk_init_partition(disk); ret = 0; unlock: mutex_unlock(&q->sysfs_lock); + /* + * Init partitions after releasing 'sysfs_lock', otherwise lockdep + * will be confused because it will treat 'bd_mutex' from different + * devices as the same lock. + */ + if (!ret) + disk_init_partition(disk); /* * SCSI probing may synchronously create and destroy a lot of -- 2.25.1

From: Ming Lei <ming.lei@redhat.com> mainline inclusion from mainline-v5.10 commit 673235f915318ced5d7ec4b2bfd8cb909e6a4a55 category: bugfix bugzilla: 187359, https://gitee.com/openeuler/kernel/issues/I5JQFO CVE: NA -------------------------------- When queuing I/O request to LLD, STS_RESOURCE may be returned because: - Host is in recovery or blocked - Target queue throttling or target is blocked - LLD rejection In these scenarios BLK_STS_DEV_RESOURCE is returned to the block layer to avoid an unnecessary re-run of the queue. However, all of the requests queued to this SCSI device may complete immediately after reading 'sdev->device_busy' and BLK_STS_DEV_RESOURCE is returned to block layer. In that case the current I/O won't get a chance to get queued since it is invisible at that time for both scsi_run_queue_async() and blk-mq's RESTART. Fix the issue by not returning BLK_STS_DEV_RESOURCE in this situation. Link: https://lore.kernel.org/r/20201202100419.525144-1-ming.lei@redhat.com Fixes: 86ff7c2a80cd ("blk-mq: introduce BLK_STS_DEV_RESOURCE") Cc: Hannes Reinecke <hare@suse.com> Cc: Sumit Saxena <sumit.saxena@broadcom.com> Cc: Kashyap Desai <kashyap.desai@broadcom.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Ewan Milne <emilne@redhat.com> Cc: Long Li <longli@microsoft.com> Reported-by: John Garry <john.garry@huawei.com> Tested-by: "chenxiang (M)" <chenxiang66@hisilicon.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> --- drivers/scsi/scsi_lib.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 5c6e05bbcb68..719cdf5628ec 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2233,8 +2233,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, case BLK_STS_OK: break; case BLK_STS_RESOURCE: - if (atomic_read(&sdev->device_busy) || - scsi_device_blocked(sdev)) + if (scsi_device_blocked(sdev)) ret = BLK_STS_DEV_RESOURCE; break; default: -- 2.25.1
participants (1)
-
Yongqiang Liu