Unverified Commit 87e496fb authored by openeuler-ci-bot's avatar openeuler-ci-bot Committed by Gitee
Browse files

!4737 blk-mq: fix IO hang from sbitmap wakeup race 

Merge Pull Request from: @ci-robot 
 
PR sync from: Li Lingfeng <lilingfeng3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/X4NOJSSOIJJK25PURVREUMAKPGU6JLO4/ 
 
https://gitee.com/openeuler/kernel/issues/I943Q7 
 
Link:https://gitee.com/openeuler/kernel/pulls/4737

 

Reviewed-by: default avatarYu Kuai <yukuai3@huawei.com>
Reviewed-by: default avatarJialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: default avatarJialin Zhang <zhangjialin11@huawei.com>
parents 02fae8ae 0169005b

block/blk-mq.c

+16 −0
Original line number Diff line number Diff line
@@ -1277,6 +1277,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