[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/7] block/nvme: don't access CQE after moving cq.head
From: |
Sergio Lopez |
Subject: |
Re: [PATCH 3/7] block/nvme: don't access CQE after moving cq.head |
Date: |
Mon, 25 May 2020 10:12:41 +0200 |
On Tue, May 19, 2020 at 06:11:34PM +0100, Stefan Hajnoczi wrote:
> Do not access a CQE after incrementing q->cq.head and releasing q->lock.
> It is unlikely that this causes problems in practice but it's a latent
> bug.
>
> The reason why it should be safe at the moment is that completion
> processing is not re-entrant and the CQ doorbell isn't written until the
> end of nvme_process_completion().
>
> Make this change now because QEMU expects completion processing to be
> re-entrant and later patches will do that.
>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
> block/nvme.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Sergio Lopez <address@hidden>
signature.asc
Description: PGP signature
- [PATCH 0/7] block/nvme: support nested aio_poll(), Stefan Hajnoczi, 2020/05/19
- [PATCH 1/7] block/nvme: poll queues without q->lock, Stefan Hajnoczi, 2020/05/19
- [PATCH 2/7] block/nvme: drop tautologous assertion, Stefan Hajnoczi, 2020/05/19
- [PATCH 3/7] block/nvme: don't access CQE after moving cq.head, Stefan Hajnoczi, 2020/05/19
- [PATCH 4/7] block/nvme: switch to a NVMeRequest freelist, Stefan Hajnoczi, 2020/05/19
- [PATCH 5/7] block/nvme: clarify that free_req_queue is protected by q->lock, Stefan Hajnoczi, 2020/05/19
- [PATCH 6/7] block/nvme: keep BDRVNVMeState pointer in NVMeQueuePair, Stefan Hajnoczi, 2020/05/19