From: "Michael S. Tsirkin" <mst@redhat.com>
To: Abhin Parekadan Jose <abhinjoses@gmail.com>
Cc: jasowangio@gmail.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, virtualization@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] virtio_pci_modern: avoid infinite loop in vp_reset() on invalid status
Date: Sun, 2 Aug 2026 14:06:39 -0400 [thread overview]
Message-ID: <20260802134301-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260802174059.4082-3-abhinjoses@gmail.com>
On Sun, Aug 02, 2026 at 05:40:59PM +0000, Abhin Parekadan Jose wrote:
> vp_reset() polls device_status in a tight loop, waiting for it to read
> back as 0 after the reset write. device_status is read via MMIO from
> the common configuration structure, which requires the PCI_COMMAND
> Memory Space Enable bit to be set. If that bit is cleared while the
> device is bound -- e.g. by writing 0x0000 to PCI_COMMAND (config space
> offset 4)
So don't do it?
> -- the MMIO read no longer reaches the device and returns
> the bus's synthesized all-ones response instead. Since that value can
> never legitimately clear to 0, the loop spins forever and hangs the
> caller.
>
> Use VIRTIO_STATUS_ERROR() to recognize such values and bail out of the
> poll loop instead of looping indefinitely.
If you want to work on suprise removal, that is great, but
with actual surprise removal testing, please. I'm not
inclined to include changes when testing amounted
to illegally poking at pci command, and without much in the way
of what effect this has on the drivers.
In particular, please read cover.1752094439.git.mst@redhat.com - a thread
where we seem to have come to the conclusion that hangs where
surprise removal happens while the remove callback is in progress
are fundamentally unfixable without pci (and likely acpi) core
changes.
>
> Signed-off-by: Abhin Parekadan Jose <abhinjoses@gmail.com>
> ---
> drivers/virtio/virtio_pci_modern.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_pci_modern.c b/drivers/virtio/virtio_pci_modern.c
> index 6d8ae2a6a8ca..209fa3b36c90 100644
> --- a/drivers/virtio/virtio_pci_modern.c
> +++ b/drivers/virtio/virtio_pci_modern.c
> @@ -547,6 +547,7 @@ static void vp_reset(struct virtio_device *vdev)
> {
> struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> struct virtio_pci_modern_device *mdev = &vp_dev->mdev;
> + u8 status;
>
> /* 0 status means a reset. */
> vp_modern_set_status(mdev, 0);
> @@ -555,8 +556,11 @@ static void vp_reset(struct virtio_device *vdev)
> * This will flush out the status write, and flush in device writes,
> * including MSI-X interrupts, if any.
> */
> - while (vp_modern_get_status(mdev))
> + while ((status = vp_modern_get_status(mdev))) {
> + if (VIRTIO_STATUS_ERROR(status))
> + break;
> msleep(1);
> + }
I am not convinced we'll never use all status bits eventually.
Currently a single bit (32, bit 5) is unused.
And then this test will give false positives.
>
> vp_modern_avq_cleanup(vdev);
>
> --
> 2.51.1
next prev parent reply other threads:[~2026-08-02 18:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 17:40 [PATCH 0/2] virtio_pci_modern: fix vp_reset() hang on unresponsive device Abhin Parekadan Jose
2026-08-02 17:40 ` [PATCH 1/2] virtio_pci_modern_dev: warn once on invalid status Abhin Parekadan Jose
2026-08-02 18:10 ` Michael S. Tsirkin
2026-08-02 17:40 ` [PATCH 2/2] virtio_pci_modern: avoid infinite loop in vp_reset() " Abhin Parekadan Jose
2026-08-02 18:06 ` Michael S. Tsirkin [this message]
2026-08-02 17:47 ` [PATCH 0/2] virtio_pci_modern: fix vp_reset() hang on unresponsive device Michael S. Tsirkin
2026-08-02 18:28 ` Abhin Parekadan Jose
2026-08-02 19:08 ` Michael S. Tsirkin
2026-08-02 19:48 ` Abhin Parekadan Jose
2026-08-02 19:54 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260802134301-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=abhinjoses@gmail.com \
--cc=eperezma@redhat.com \
--cc=jasowangio@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox