Re: [syzbot] memory leak in blk_iolatency_init (2)

[Ming Lei <ming.lei-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Sat, Mar 12, 2022 at 01:45:25PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    79b00034e9dc Merge tag 'drm-fixes-2022-03-11' of git://ano..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15cf8329700000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c9e1a3a8e38b9582
> dashboard link: https://syzkaller.appspot.com/bug?extid=b42749a851a47a0f581b
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101cc4ee700000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1270b5e9700000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b42749a851a47a0f581b-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8@public.gmane.org
> 
> BUG: memory leak
> unreferenced object 0xffff888103f8fa00 (size 96):
>   comm "kworker/u4:0", pid 8, jiffies 4294937736 (age 503.480s)
>   hex dump (first 32 bytes):
>     40 5d ca 85 ff ff ff ff 38 c8 26 04 81 88 ff ff  @]......8.&.....
>     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff8228f408>] kmalloc include/linux/slab.h:581 [inline]
>     [<ffffffff8228f408>] kzalloc include/linux/slab.h:714 [inline]
>     [<ffffffff8228f408>] blk_iolatency_init+0x28/0x190 block/blk-iolatency.c:725
>     [<ffffffff82285ede>] blkcg_init_queue+0xee/0x1c0 block/blk-cgroup.c:1206
>     [<ffffffff8224b1aa>] blk_alloc_queue+0x24a/0x4a0 block/blk-core.c:495
>     [<ffffffff822647a5>] blk_mq_init_queue_data block/blk-mq.c:3883 [inline]
>     [<ffffffff822647a5>] blk_mq_init_queue+0x35/0x90 block/blk-mq.c:3897
>     [<ffffffff8277f2b1>] scsi_alloc_sdev+0x231/0x3b0 drivers/scsi/scsi_scan.c:330
>     [<ffffffff82780425>] scsi_probe_and_add_lun+0xff5/0x17e0 drivers/scsi/scsi_scan.c:1167
>     [<ffffffff827812df>] __scsi_scan_target+0x14f/0x9a0 drivers/scsi/scsi_scan.c:1649
>     [<ffffffff82781da7>] scsi_scan_channel drivers/scsi/scsi_scan.c:1737 [inline]
>     [<ffffffff82781da7>] scsi_scan_channel+0xb7/0x100 drivers/scsi/scsi_scan.c:1713
>     [<ffffffff82781faf>] scsi_scan_host_selected+0x1bf/0x220 drivers/scsi/scsi_scan.c:1766
>     [<ffffffff827820d0>] do_scsi_scan_host+0xc0/0xd0 drivers/scsi/scsi_scan.c:1905
>     [<ffffffff82782359>] do_scan_async+0x19/0x200 drivers/scsi/scsi_scan.c:1915
>     [<ffffffff8127cff4>] async_run_entry_fn+0x24/0xf0 kernel/async.c:127
>     [<ffffffff8126b43f>] process_one_work+0x2bf/0x600 kernel/workqueue.c:2307
>     [<ffffffff8126bd69>] worker_thread+0x59/0x5b0 kernel/workqueue.c:2454
>     [<ffffffff81275725>] kthread+0x125/0x160 kernel/kthread.c:377
>     [<ffffffff810021ef>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

This is caused by 8e141f9eb803 ("block: drain file system I/O on del_gendisk").

rq_qos_exit() is for calling blkcg_iolatency_exit() to release data
allocated in blk_iolatency_init(). Since 8e141f9eb803, rq_qos_exit() is
moved to del_gendisk() from blk_cleanup_queue, it becomes not possible
to free the data when scanning un-present luns.

The following patch should fix it for v5.16/v5.17, and V5.18 needn't that
since v5.18 will move blkcg init/uninit into gendisk alloc/release.


diff --git a/block/blk-core.c b/block/blk-core.c
index ce08f0aa9dfc..1ea7e523960c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -321,6 +321,7 @@ void blk_cleanup_queue(struct request_queue *q)
 	 */
 	blk_freeze_queue(q);
 
+	rq_qos_exit(q);
 	blk_queue_flag_set(QUEUE_FLAG_DEAD, q);
 
 	blk_sync_queue(q);


Thanks,
Ming