[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [PULL 10/25] virtio_error: don't invoke status callbac
From: |
Peter Lieven |
Subject: |
Re: [Qemu-stable] [PULL 10/25] virtio_error: don't invoke status callbacks |
Date: |
Tue, 13 Feb 2018 21:53:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
Am 21.12.2017 um 15:29 schrieb Michael S. Tsirkin:
> Backends don't need to know what frontend requested a reset,
> and notifying then from virtio_error is messy because
> virtio_error itself might be invoked from backend.
>
> Let's just set the status directly.
>
> Cc: address@hidden
> Reported-by: Ilya Maximets <address@hidden>
> Signed-off-by: Michael S. Tsirkin <address@hidden>
> ---
> hw/virtio/virtio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index ad564b0..d6002ee 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -2469,7 +2469,7 @@ void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice
> *vdev, const char *fmt, ...)
> va_end(ap);
>
> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> - virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
> + vdev->status = vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET;
> virtio_notify_config(vdev);
> }
>
Is it possible that this patch introduces a stall in I/O and a deadlock on a
drain all?
I have seen Qemu VMs being I/O stalled and deadlocking on a vm stop command in
blk_drain_all. This happened after a longer storage outage.
I am asking just theoretically because I have seen this behaviour first when we
backported this patch in our stable 2.9 branch.
Thank you,
Peter
- Re: [Qemu-stable] [PULL 10/25] virtio_error: don't invoke status callbacks,
Peter Lieven <=