FAILED: patch "[PATCH] block: fix missing dispatching request when queue is started" failed to apply to 5.15-stable tree

FAILED: patch "[PATCH] block: fix missing dispatching request when queue is started" failed to apply to 5.15-stable tree

[gregkh]

The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 2003ee8a9aa14d766b06088156978d53c2e9be3d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024120323-snowiness-subway-3844@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 2003ee8a9aa14d766b06088156978d53c2e9be3d Mon Sep 17 00:00:00 2001
From: Muchun Song <muchun.song@linux.dev>
Date: Mon, 14 Oct 2024 17:29:32 +0800
Subject: [PATCH] block: fix missing dispatching request when queue is started
 or unquiesced

Supposing the following scenario with a virtio_blk driver.

CPU0                    CPU1                    CPU2

blk_mq_try_issue_directly()
  __blk_mq_issue_directly()
    q->mq_ops->queue_rq()
      virtio_queue_rq()
        blk_mq_stop_hw_queue()
                                                virtblk_done()
                        blk_mq_try_issue_directly()
                          if (blk_mq_hctx_stopped())
  blk_mq_request_bypass_insert()                  blk_mq_run_hw_queue()
  blk_mq_run_hw_queue()     blk_mq_run_hw_queue()
                            blk_mq_insert_request()
                            return

After CPU0 has marked the queue as stopped, CPU1 will see the queue is
stopped. But before CPU1 puts the request on the dispatch list, CPU2
receives the interrupt of completion of request, so it will run the
hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also
runs the same hardware queue. After both CPU1 and CPU2 complete
blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware
queue and returns. It misses dispatching a request. Fix it by running
the hardware queue explicitly. And blk_mq_request_issue_directly()
should handle a similar situation. Fix it as well.

Fixes: d964f04a8fde ("blk-mq: fix direct issue")
Cc: stable@vger.kernel.org
Cc: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 7d05a56e3639..5deb9dffca0a 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2647,6 +2647,7 @@ static void blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx,
 
 	if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(rq->q)) {
 		blk_mq_insert_request(rq, 0);
+		blk_mq_run_hw_queue(hctx, false);
 		return;
 	}
 
@@ -2677,6 +2678,7 @@ static blk_status_t blk_mq_request_issue_directly(struct request *rq, bool last)
 
 	if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(rq->q)) {
 		blk_mq_insert_request(rq, 0);
+		blk_mq_run_hw_queue(hctx, false);
 		return BLK_STS_OK;
 	}
 

[PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Muchun Song]

Supposing the following scenario with a virtio_blk driver.

CPU0                    CPU1                    CPU2

blk_mq_try_issue_directly()
  __blk_mq_issue_directly()
    q->mq_ops->queue_rq()
      virtio_queue_rq()
        blk_mq_stop_hw_queue()
                                                virtblk_done()
                        blk_mq_try_issue_directly()
                          if (blk_mq_hctx_stopped())
  blk_mq_request_bypass_insert()                  blk_mq_run_hw_queue()
  blk_mq_run_hw_queue()     blk_mq_run_hw_queue()
                            blk_mq_insert_request()
                            return

After CPU0 has marked the queue as stopped, CPU1 will see the queue is
stopped. But before CPU1 puts the request on the dispatch list, CPU2
receives the interrupt of completion of request, so it will run the
hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also
runs the same hardware queue. After both CPU1 and CPU2 complete
blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware
queue and returns. It misses dispatching a request. Fix it by running
the hardware queue explicitly. And blk_mq_request_issue_directly()
should handle a similar situation. Fix it as well.

Fixes: d964f04a8fde ("blk-mq: fix direct issue")
Cc: stable@vger.kernel.org
Cc: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 block/blk-mq.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 46cb802cfcf05..a15c665a77100 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2048,7 +2048,6 @@ static blk_status_t __blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx,
 	 * and avoid driver to try to dispatch again.
 	 */
 	if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q)) {
-		run_queue = false;
 		bypass_insert = false;
 		goto insert;
 	}
-- 
2.20.1

Re: [PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Greg KH]

On Mon, Mar 17, 2025 at 11:30:39AM +0800, Muchun Song wrote:
> Supposing the following scenario with a virtio_blk driver.
> 
> CPU0                    CPU1                    CPU2
> 
> blk_mq_try_issue_directly()
>   __blk_mq_issue_directly()
>     q->mq_ops->queue_rq()
>       virtio_queue_rq()
>         blk_mq_stop_hw_queue()
>                                                 virtblk_done()
>                         blk_mq_try_issue_directly()
>                           if (blk_mq_hctx_stopped())
>   blk_mq_request_bypass_insert()                  blk_mq_run_hw_queue()
>   blk_mq_run_hw_queue()     blk_mq_run_hw_queue()
>                             blk_mq_insert_request()
>                             return
> 
> After CPU0 has marked the queue as stopped, CPU1 will see the queue is
> stopped. But before CPU1 puts the request on the dispatch list, CPU2
> receives the interrupt of completion of request, so it will run the
> hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also
> runs the same hardware queue. After both CPU1 and CPU2 complete
> blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware
> queue and returns. It misses dispatching a request. Fix it by running
> the hardware queue explicitly. And blk_mq_request_issue_directly()
> should handle a similar situation. Fix it as well.
> 
> Fixes: d964f04a8fde ("blk-mq: fix direct issue")
> Cc: stable@vger.kernel.org
> Cc: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> Reviewed-by: Ming Lei <ming.lei@redhat.com>
> Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> ---
>  block/blk-mq.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 46cb802cfcf05..a15c665a77100 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -2048,7 +2048,6 @@ static blk_status_t __blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx,
>  	 * and avoid driver to try to dispatch again.
>  	 */
>  	if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q)) {
> -		run_queue = false;
>  		bypass_insert = false;
>  		goto insert;
>  	}
> -- 
> 2.20.1
> 
> 

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

Summary of potential issues:
⚠️ Found matching upstream commit but patch is missing proper reference to it

Found matching upstream commit: 2003ee8a9aa14d766b06088156978d53c2e9be3d

Status in newer kernel trees:
6.13.y | Present (exact SHA1)
6.12.y | Present (different SHA1: 8b25c0a165dd)
6.6.y | Present (different SHA1: fe0d9800ead6)
6.1.y | Not found

Note: The patch differs from the upstream commit:
---
1:  2003ee8a9aa14 < -:  ------------- block: fix missing dispatching request when queue is started or unquiesced
-:  ------------- > 1:  ee890aaab4d74 block: fix missing dispatching request when queue is started or unquiesced
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.15.y       |  Success    |  Success   |

[PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Muchun Song]

Supposing the following scenario with a virtio_blk driver.

CPU0                    CPU1                    CPU2

blk_mq_try_issue_directly()
  __blk_mq_issue_directly()
    q->mq_ops->queue_rq()
      virtio_queue_rq()
        blk_mq_stop_hw_queue()
                                                virtblk_done()
                        blk_mq_try_issue_directly()
                          if (blk_mq_hctx_stopped())
  blk_mq_request_bypass_insert()                  blk_mq_run_hw_queue()
  blk_mq_run_hw_queue()     blk_mq_run_hw_queue()
                            blk_mq_insert_request()
                            return

After CPU0 has marked the queue as stopped, CPU1 will see the queue is
stopped. But before CPU1 puts the request on the dispatch list, CPU2
receives the interrupt of completion of request, so it will run the
hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also
runs the same hardware queue. After both CPU1 and CPU2 complete
blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware
queue and returns. It misses dispatching a request. Fix it by running
the hardware queue explicitly. And blk_mq_request_issue_directly()
should handle a similar situation. Fix it as well.

Fixes: d964f04a8fde ("blk-mq: fix direct issue")
Cc: stable@vger.kernel.org
Cc: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 2003ee8a9aa14d766b06088156978d53c2e9be3d)
---
 block/blk-mq.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 46cb802cfcf05..a15c665a77100 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2048,7 +2048,6 @@ static blk_status_t __blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx,
 	 * and avoid driver to try to dispatch again.
 	 */
 	if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q)) {
-		run_queue = false;
 		bypass_insert = false;
 		goto insert;
 	}
-- 
2.20.1

Re: [PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

Summary of potential issues:
⚠️ Found matching upstream commit but patch is missing proper reference to it

Found matching upstream commit: 2003ee8a9aa14d766b06088156978d53c2e9be3d

Status in newer kernel trees:
6.13.y | Present (exact SHA1)
6.12.y | Present (different SHA1: 8b25c0a165dd)
6.6.y | Present (different SHA1: fe0d9800ead6)
6.1.y | Not found

Note: The patch differs from the upstream commit:
---
1:  2003ee8a9aa14 < -:  ------------- block: fix missing dispatching request when queue is started or unquiesced
-:  ------------- > 1:  78009b03feb87 block: fix missing dispatching request when queue is started or unquiesced
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.15.y       |  Success    |  Success   |

Re: [PATCH 5.15.y] block: fix missing dispatching request when queue is started or unquiesced

[Greg KH]

On Mon, Mar 17, 2025 at 03:18:21PM +0800, Muchun Song wrote:
> Supposing the following scenario with a virtio_blk driver.
> 
> CPU0                    CPU1                    CPU2
> 
> blk_mq_try_issue_directly()
>   __blk_mq_issue_directly()
>     q->mq_ops->queue_rq()
>       virtio_queue_rq()
>         blk_mq_stop_hw_queue()
>                                                 virtblk_done()
>                         blk_mq_try_issue_directly()
>                           if (blk_mq_hctx_stopped())
>   blk_mq_request_bypass_insert()                  blk_mq_run_hw_queue()
>   blk_mq_run_hw_queue()     blk_mq_run_hw_queue()
>                             blk_mq_insert_request()
>                             return
> 
> After CPU0 has marked the queue as stopped, CPU1 will see the queue is
> stopped. But before CPU1 puts the request on the dispatch list, CPU2
> receives the interrupt of completion of request, so it will run the
> hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also
> runs the same hardware queue. After both CPU1 and CPU2 complete
> blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware
> queue and returns. It misses dispatching a request. Fix it by running
> the hardware queue explicitly. And blk_mq_request_issue_directly()
> should handle a similar situation. Fix it as well.
> 
> Fixes: d964f04a8fde ("blk-mq: fix direct issue")
> Cc: stable@vger.kernel.org
> Cc: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> Reviewed-by: Ming Lei <ming.lei@redhat.com>
> Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> (cherry picked from commit 2003ee8a9aa14d766b06088156978d53c2e9be3d)

This was NOT a clean cherry-pick, always document what you had to do
differently from the original change please.

Please fix this up and resend a new version.

thanks,

greg k-h