[PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support

[PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support

[Yuho Choi]

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

Re: [PATCH v1] virtio-mem: only mark the device ready in kdump mode with vmcore support

[David Hildenbrand (Arm)]

On 10/16/26 04:35, Yuho Choi wrote:
> 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

Which kdump kernel exists that does not enable CONFIG_PROC_VMCORE?

IOW, why should this be stable material?


> 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

LGTM, but I am pretty sure it does not make any difference in practice?

-- 
Cheers,

David