thebeanogamer / rpms / qemu-kvm

Forked from rpms/qemu-kvm 5 months ago
Clone

Blame SOURCES/kvm-block-nvme-fix-infinite-loop-in-nvme_free_req_queue_.patch

495e37
From 6989be9d0aa08470f8b287c243dc4bf027d5fbcf Mon Sep 17 00:00:00 2001
495e37
From: Stefan Hajnoczi <stefanha@redhat.com>
495e37
Date: Wed, 8 Dec 2021 15:22:46 +0000
495e37
Subject: [PATCH 1/2] block/nvme: fix infinite loop in nvme_free_req_queue_cb()
495e37
MIME-Version: 1.0
495e37
Content-Type: text/plain; charset=UTF-8
495e37
Content-Transfer-Encoding: 8bit
495e37
495e37
RH-Author: Stefan Hajnoczi <stefanha@redhat.com>
495e37
RH-MergeRequest: 58: block/nvme: fix infinite loop in nvme_free_req_queue_cb()
495e37
RH-Commit: [1/1] 544b3f310d791a20c63b51947de0c6cbb60b0d5b (stefanha/centos-stream-qemu-kvm)
495e37
RH-Bugzilla: 2024544
495e37
RH-Acked-by: Kevin Wolf <kwolf@redhat.com>
495e37
RH-Acked-by: Stefano Garzarella <sgarzare@redhat.com>
495e37
RH-Acked-by: Hanna Reitz <hreitz@redhat.com>
495e37
495e37
When the request free list is exhausted the coroutine waits on
495e37
q->free_req_queue for the next free request. Whenever a request is
495e37
completed a BH is scheduled to invoke nvme_free_req_queue_cb() and wake
495e37
up waiting coroutines.
495e37
495e37
1. nvme_get_free_req() waits for a free request:
495e37
495e37
    while (q->free_req_head == -1) {
495e37
        ...
495e37
            trace_nvme_free_req_queue_wait(q->s, q->index);
495e37
            qemu_co_queue_wait(&q->free_req_queue, &q->lock);
495e37
        ...
495e37
    }
495e37
495e37
2. nvme_free_req_queue_cb() wakes up the coroutine:
495e37
495e37
    while (qemu_co_enter_next(&q->free_req_queue, &q->lock)) {
495e37
       ^--- infinite loop when free_req_head == -1
495e37
    }
495e37
495e37
nvme_free_req_queue_cb() and the coroutine form an infinite loop when
495e37
q->free_req_head == -1. Fix this by checking q->free_req_head in
495e37
nvme_free_req_queue_cb(). If the free request list is exhausted, don't
495e37
wake waiting coroutines. Eventually an in-flight request will complete
495e37
and the BH will be scheduled again, guaranteeing forward progress.
495e37
495e37
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
495e37
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
495e37
Message-id: 20211208152246.244585-1-stefanha@redhat.com
495e37
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
495e37
(cherry picked from commit cf4fbc3030c974fff726756a7ceef8386cdf500b)
495e37
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
495e37
---
495e37
 block/nvme.c | 5 +++--
495e37
 1 file changed, 3 insertions(+), 2 deletions(-)
495e37
495e37
diff --git a/block/nvme.c b/block/nvme.c
495e37
index e4f336d79c..fa360b9b3c 100644
495e37
--- a/block/nvme.c
495e37
+++ b/block/nvme.c
495e37
@@ -206,8 +206,9 @@ static void nvme_free_req_queue_cb(void *opaque)
495e37
     NVMeQueuePair *q = opaque;
495e37
 
495e37
     qemu_mutex_lock(&q->lock);
495e37
-    while (qemu_co_enter_next(&q->free_req_queue, &q->lock)) {
495e37
-        /* Retry all pending requests */
495e37
+    while (q->free_req_head != -1 &&
495e37
+           qemu_co_enter_next(&q->free_req_queue, &q->lock)) {
495e37
+        /* Retry waiting requests */
495e37
     }
495e37
     qemu_mutex_unlock(&q->lock);
495e37
 }
495e37
-- 
495e37
2.27.0
495e37