diff options
Diffstat (limited to 'meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch')
| -rw-r--r-- | meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch new file mode 100644 index 000000000..9e9fedb09 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch @@ -0,0 +1,70 @@ +From 1d9c777d3e70bdc57dddf7a14a80059d65919e56 Mon Sep 17 00:00:00 2001 +From: Ming Lei <ming.lei@redhat.com> +Date: Fri, 12 Jan 2024 20:26:26 +0800 +Subject: blk-mq: fix IO hang from sbitmap wakeup race + +[ Upstream commit 5266caaf5660529e3da53004b8b7174cab6374ed ] + +In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered +with the following blk_mq_get_driver_tag() in case of getting driver +tag failure. + +Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe +the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime +blk_mq_mark_tag_wait() can't get driver tag successfully. + +This issue can be reproduced by running the following test in loop, and +fio hang can be observed in < 30min when running it on my test VM +in laptop. + + modprobe -r scsi_debug + modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 + dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` + fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ + --runtime=100 --numjobs=40 --time_based --name=test \ + --ioengine=libaio + +Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which +is just fine in case of running out of tag. + +Cc: Jan Kara <jack@suse.cz> +Cc: Kemeng Shi <shikemeng@huaweicloud.com> +Reported-by: Changhui Zhong <czhong@redhat.com> +Signed-off-by: Ming Lei <ming.lei@redhat.com> +Link: https://lore.kernel.org/r/20240112122626.4181044-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe <axboe@kernel.dk> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + block/blk-mq.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +diff --git a/block/blk-mq.c b/block/blk-mq.c +index b3f99dda45300a..c07e5eebcbd853 100644 +--- a/block/blk-mq.c ++++ b/block/blk-mq.c +@@ -1859,6 +1859,22 @@ static bool blk_mq_mark_tag_wait(struct blk_mq_hw_ctx *hctx, + wait->flags &= ~WQ_FLAG_EXCLUSIVE; + __add_wait_queue(wq, wait); + ++ /* ++ * Add one explicit barrier since blk_mq_get_driver_tag() may ++ * not imply barrier in case of failure. ++ * ++ * Order adding us to wait queue and allocating driver tag. ++ * ++ * The pair is the one implied in sbitmap_queue_wake_up() which ++ * orders clearing sbitmap tag bits and waitqueue_active() in ++ * __sbitmap_queue_wake_up(), since waitqueue_active() is lockless ++ * ++ * Otherwise, re-order of adding wait queue and getting driver tag ++ * may cause __sbitmap_queue_wake_up() to wake up nothing because ++ * the waitqueue_active() may not observe us in wait queue. ++ */ ++ smp_mb(); ++ + /* + * It's possible that a tag was freed in the window between the + * allocation failure and adding the hardware queue to the wait +-- +cgit 1.2.3-korg + |