* [PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support
@ 2026-10-16 2:35 Yuho Choi
2026-10-16 2:45 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Yuho Choi @ 2026-10-16 2:35 UTC (permalink / raw)
To: David Hildenbrand, Michael S. Tsirkin
Cc: Jason Wang, Eugenio Pérez, Xuan Zhuo, virtualization,
linux-kernel, Yuho Choi, stable
virtio_mem_init_kdump() marks the device DRIVER_OK before it checks for
CONFIG_PROC_VMCORE. Without vmcore support it then fails with -EBUSY,
and virtio_mem_probe() deletes the virtqueue on that error path without
resetting the device first, so the device is left believing the driver
is ready while its queue points at memory that has been freed.
Before commit a9403425b3cf ("virtio-mem: mark device ready before
registering callbacks in kdump mode"), virtio_mem_probe() called
virtio_device_ready() only after virtio_mem_init() had succeeded, so this
path never exposed a ready device.
Move virtio_device_ready() into the CONFIG_PROC_VMCORE branch, right
before the vmcore callbacks that need it are registered, so the -EBUSY
path never sets DRIVER_OK.
Fixes: a9403425b3cf ("virtio-mem: mark device ready before registering callbacks in kdump mode")
Cc: stable@vger.kernel.org
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
drivers/virtio/virtio_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index e18dd736f2ec..b28d2da7d5b6 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2817,9 +2817,9 @@ static int virtio_mem_vmcore_get_device_ram(struct vmcore_cb *cb,
static int virtio_mem_init_kdump(struct virtio_mem *vm)
{
+#ifdef CONFIG_PROC_VMCORE
/* We must be prepared to receive a callback immediately. */
virtio_device_ready(vm->vdev);
-#ifdef CONFIG_PROC_VMCORE
dev_info(&vm->vdev->dev, "memory hot(un)plug disabled in kdump kernel\n");
vm->vmcore_cb.pfn_is_ram = virtio_mem_vmcore_pfn_is_ram;
#ifdef CONFIG_PROC_VMCORE_DEVICE_RAM
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support
2026-10-16 2:35 [PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support Yuho Choi
@ 2026-10-16 2:45 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-10-16 2:45 UTC (permalink / raw)
To: Yuho Choi; +Cc: virtualization, Michael S. Tsirkin, Eugenio Perez
> virtio_mem_init_kdump() marks the device DRIVER_OK before it checks for
> CONFIG_PROC_VMCORE. Without vmcore support it then fails with -EBUSY,
> and virtio_mem_probe() deletes the virtqueue on that error path without
> resetting the device first, so the device is left believing the driver
> is ready while its queue points at memory that has been freed.
>
> Before commit a9403425b3cf ("virtio-mem: mark device ready before
> registering callbacks in kdump mode"), virtio_mem_probe() called
> virtio_device_ready() only after virtio_mem_init() had succeeded, so this
> path never exposed a ready device.
>
> Move virtio_device_ready() into the CONFIG_PROC_VMCORE branch, right
> before the vmcore callbacks that need it are registered, so the -EBUSY
> path never sets DRIVER_OK.
>
> Fixes: a9403425b3cf ("virtio-mem: mark device ready before registering callbacks in kdump mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016023521.747447-1-oss.patchbox@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-16 2:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-16 2:35 [PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support Yuho Choi
2026-10-16 2:45 ` sashiko-bot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.