On 08/12/2020 11:36, John Garry wrote:
OK, but another thing to say is that I need to find a somewhat
reliable reproducer for the potential problem you mention. So far this
patch solves the issue I see (in that kasan stops warning). Let me
analyze this a bit further.
Hi Ming,
I am just looking at this again, and have some doubt on your concern [0].
From checking blk_mq_queue_tag_busy_iter() specifically, don't we
actually guard against this with the q->q_usage_counter mechanism? That
is, an agent needs to grab a q counter ref when attempting the iter.
This will fail when the queue IO sched is being changed, as we freeze
the queue during this time, which is when the requests are freed, so no
agent can hold a reference to a freed request then. And same goes for
blk_mq_update_nr_requests(), where we freeze the queue.
But I didn't see such a guard for blk_mq_tagset_busy_iter().
So I was able to trigger a use-after-free BUG in
blk_mq_tagset_busy_iter() even with my change, but I needed to add a
delay, as follows:
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -278,6 +278,7 @@ static bool bt_tags_iter(struct sbitmap *bitmap,
unsigned int bitnr, void *data)
rq = tags->rqs[bitnr];
if (!rq)
return true;
+ msleep(50);
if ((iter_data->flags & BT_TAG_ITER_STARTED) &&
!blk_mq_request_started(rq))
return true;
And here's the splat:
[ 319.771745] BUG: KASAN: use-after-free in bt_tags_iter+0xe0/0x128
[ 319.777832] Read of size 4 at addr ffff0010b6bd27cc by task more/1866
[ 319.784262]
[ 319.785753] CPU: 61 PID: 1866 Comm: more Tainted: G W
5.10.0-rc4-18118-gaa7b9c30d8ff #1070
[ 319.795312] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
D05 IT21 Nemo 2.0 RC0 04/18/2018
[ 319.804437] Call trace:
[ 319.806892] dump_backtrace+0x0/0x2d0
[ 319.810552] show_stack+0x18/0x68
[ 319.813865] dump_stack+0x100/0x16c
[ 319.817348] print_address_description.constprop.12+0x6c/0x4e8
[ 319.823176] kasan_report+0x130/0x200
[ 319.826831] __asan_load4+0x9c/0xd8
[ 319.830315] bt_tags_iter+0xe0/0x128
[ 319.833884] __blk_mq_all_tag_iter+0x320/0x3a8
[ 319.838320] blk_mq_tagset_busy_iter+0x8c/0xd8
[ 319.842760] scsi_host_busy+0x88/0xb8
[ 319.846418] show_host_busy+0x1c/0x48
[ 319.850079] dev_attr_show+0x44/0x90
[ 319.853655] sysfs_kf_seq_show+0x128/0x1c8
[ 319.857744] kernfs_seq_show+0xa0/0xb8
[ 319.861489] seq_read_iter+0x1ec/0x6a0
[ 319.865230] seq_read+0x1d0/0x250
[ 319.868539] kernfs_fop_read+0x70/0x330
[ 319.872369] vfs_read+0xe4/0x250
[ 319.875590] ksys_read+0xc8/0x178
[ 319.878898] __arm64_sys_read+0x44/0x58
[ 319.882730] el0_svc_common.constprop.2+0xc4/0x1e8
[ 319.887515] do_el0_svc+0x90/0xa0
[ 319.890824] el0_sync_handler+0x128/0x178
[ 319.894825] el0_sync+0x158/0x180
[ 319.898131]
[ 319.899614] The buggy address belongs to the page:
[ 319.904403] page:000000004e9e6864 refcount:0 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x10b6bd2
[ 319.913876] flags: 0xbfffc0000000000()
[ 319.917626] raw: 0bfffc0000000000 0000000000000000 fffffe0000000000
0000000000000000
[ 319.925363] raw: 0000000000000000 0000000000000000 00000000ffffffff
0000000000000000
[ 319.933096] page dumped because: kasan: bad access detected
[ 319.938658]
[ 319.940141] Memory state around the buggy address:
[ 319.944925] ffff0010b6bd2680: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
[ 319.952139] ffff0010b6bd2700: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
[ 319.959354] >ffff0010b6bd2780: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
[ 319.966566] ^
[ 319.972131] ffff0010b6bd2800: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
[ 319.979344] ffff0010b6bd2880: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
[ 319.986557]
==================================================================
[ 319.993770] Disabling lock debugging due to kernel taint
So to trigger this, I start fio on a disk, and then have one script
which constantly enables and disables an IO scheduler for that disk, and
another which constantly reads /sys/class/scsi_host/host0/host_busy.
I need the delay to make triggering the issue quick, as the window is so
small between the tag bit being cleared at the point the queue is being
frozen, and clearing the reference in the tagset.
Anyway, solving this doesn't look trivial...
Thanks,
john
