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: [email protected]
Signed-off-by: Yuho Choi <[email protected]>
---
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
