[PATCH] can: virtio: fix virtqueue use before DRIVER_OK

[PATCH] can: virtio: fix virtqueue use before DRIVER_OK

[Seonghyeon Lim via B4 Relay]

From: Seonghyeon Lim <forfortuna@naver.com>

virtio_can_probe() and virtio_can_restore() fill the RX virtqueue and
kick it before the device is set DRIVER_OK. The virtio specification
does not allow the driver to notify the device before DRIVER_OK.

In restore, if the interface was up, virtio_can_open() then sends a
START control message and waits for the reply. DRIVER_OK is only set
by the virtio core after restore returns, so the device may never
handle the request and the wait never completes, which hangs system
resume. In probe, an ndo_open() right after register_candev() can
likewise send the START message before DRIVER_OK.

Call virtio_device_ready() before the first virtqueue use in both
probe and restore, as virtio-net does.

Fixes: 083082a4e6d8 ("can: virtio: Add virtio CAN driver")
Signed-off-by: Seonghyeon Lim <forfortuna@naver.com>
---
Tested with QEMU 8.2 + vhost-device-can: with the CAN interface up,
suspend/resume (pm_test=devices) hangs without this patch and
completes with it. No new lockdep warnings.
---
 drivers/net/can/virtio_can.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/can/virtio_can.c b/drivers/net/can/virtio_can.c
index f67d0bf09681..ae35a00b784b 100644
--- a/drivers/net/can/virtio_can.c
+++ b/drivers/net/can/virtio_can.c
@@ -912,6 +912,9 @@ static int virtio_can_probe(struct virtio_device *vdev)
 		err = -ENOMEM;
 		goto on_failure;
 	}
+
+	virtio_device_ready(vdev);
+
 	virtio_can_populate_rx_vq(vdev);
 
 	err = register_virtio_can_dev(dev);
@@ -966,6 +969,9 @@ static int __maybe_unused virtio_can_restore(struct virtio_device *vdev)
 		virtio_can_del_vq(vdev);
 		return -ENOMEM;
 	}
+
+	virtio_device_ready(vdev);
+
 	virtio_can_populate_rx_vq(vdev);
 
 	if (netif_running(ndev)) {

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
change-id: 20261111-virtio-can-ready-85cefff06a84

Best regards,
--  
Seonghyeon Lim <forfortuna@naver.com>

Re: [PATCH] can: virtio: fix virtqueue use before DRIVER_OK

[Michael S. Tsirkin]

On Wed, Nov 11, 2026 at 02:11:13AM +0900, Seonghyeon Lim via B4 Relay wrote:
> From: Seonghyeon Lim <forfortuna@naver.com>
> 
> virtio_can_probe() and virtio_can_restore() fill the RX virtqueue and
> kick it before the device is set DRIVER_OK. The virtio specification
> does not allow the driver to notify the device before DRIVER_OK.
> 
> In restore, if the interface was up, virtio_can_open() then sends a
> START control message and waits for the reply. DRIVER_OK is only set
> by the virtio core after restore returns, so the device may never
> handle the request and the wait never completes, which hangs system
> resume. In probe, an ndo_open() right after register_candev() can
> likewise send the START message before DRIVER_OK.
> 
> Call virtio_device_ready() before the first virtqueue use in both
> probe and restore, as virtio-net does.
> 
> Fixes: 083082a4e6d8 ("can: virtio: Add virtio CAN driver")
> Signed-off-by: Seonghyeon Lim <forfortuna@naver.com>

however, device ready means you can get callbacks: config
and vq.


did you audit the driver to make sure this is safe while
probe did not yet populate and register the device?

> ---

> Tested with QEMU 8.2 + vhost-device-can: with the CAN interface up,
> suspend/resume (pm_test=devices) hangs without this patch and
> completes with it. No new lockdep warnings.
> ---
>  drivers/net/can/virtio_can.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/can/virtio_can.c b/drivers/net/can/virtio_can.c
> index f67d0bf09681..ae35a00b784b 100644
> --- a/drivers/net/can/virtio_can.c
> +++ b/drivers/net/can/virtio_can.c
> @@ -912,6 +912,9 @@ static int virtio_can_probe(struct virtio_device *vdev)
>  		err = -ENOMEM;
>  		goto on_failure;
>  	}
> +
> +	virtio_device_ready(vdev);
> +
>  	virtio_can_populate_rx_vq(vdev);
>  
>  	err = register_virtio_can_dev(dev);
> @@ -966,6 +969,9 @@ static int __maybe_unused virtio_can_restore(struct virtio_device *vdev)
>  		virtio_can_del_vq(vdev);
>  		return -ENOMEM;
>  	}
> +
> +	virtio_device_ready(vdev);
> +
>  	virtio_can_populate_rx_vq(vdev);
>  
>  	if (netif_running(ndev)) {
> 
> ---
> base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
> change-id: 20261111-virtio-can-ready-85cefff06a84
> 
> Best regards,
> --  
> Seonghyeon Lim <forfortuna@naver.com>
> 

Re: [PATCH] can: virtio: fix virtqueue use before DRIVER_OK

[임성현]

On Tue, Nov 10, 2026 at 12:26:..., Michael S. Tsirkin wrote:
> however, device ready means you can get callbacks: config
> and vq.
>
> did you audit the driver to make sure this is safe while
> probe did not yet populate and register the device?

Thanks for the review.

Config callbacks are fine: config_core_enabled stays false until
probe/restore returns, so a config change is deferred until then.

For vq callbacks, there is a real problem, also reported by
sashiko-bot: an RX/TX interrupt that arrives before
virtio_can_napi_enable() in virtio_can_open() calls
virtqueue_disable_cb() while NAPI is still disabled, so the queue
stalls. This already exists in the open path, but with this patch
restore can now reach it.

I will fix that first in a separate patch and send v2 as a
two-patch series.

Thanks,
Seonghyeon

Re: [PATCH] can: virtio: fix virtqueue use before DRIVER_OK

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] can: virtio: RX/TX stall if interrupt fires before
  virtio_can_napi_enable()
--

commit 8c2e9ab878f651e327c76d0ed7de23824865f16e
Author: Seonghyeon Lim <forfortuna@naver.com>

can: virtio: fix virtqueue use before DRIVER_OK

This commit calls virtio_device_ready() before populating the RX virtqueue
in virtio_can_probe() and virtio_can_restore() so that virtqueues are not
notified before DRIVER_OK is set.

> diff --git a/drivers/net/can/virtio_can.c b/drivers/net/can/virtio_can.c
> index f67d0bf09681f..ae35a00b784bd 100644
> --- a/drivers/net/can/virtio_can.c
> +++ b/drivers/net/can/virtio_can.c
> @@ -912,6 +912,9 @@ static int virtio_can_probe(struct virtio_device *vdev)
>  		err = -ENOMEM;
>  		goto on_failure;
>  	}
> +
> +	virtio_device_ready(vdev);
> +
>  	virtio_can_populate_rx_vq(vdev);
>  
>  	err = register_virtio_can_dev(dev);
> @@ -966,6 +969,9 @@ static int __maybe_unused virtio_can_restore(struct virtio_device *vdev)
>  		virtio_can_del_vq(vdev);
>  		return -ENOMEM;
>  	}
> +
> +	virtio_device_ready(vdev);
> +
>  	virtio_can_populate_rx_vq(vdev);
>  
>  	if (netif_running(ndev)) {

[Severity: High]
Can an RX or TX virtqueue interrupt arriving before
virtio_can_napi_enable() permanently wedge the queue?

virtio_device_ready() unbreaks the virtqueues and sets DRIVER_OK while
priv->napi and priv->napi_tx are still disabled (NAPI_STATE_SCHED is set).
In virtio_can_open(), virtio_can_start() then sends
VIRTIO_CAN_SET_CTRL_MODE_START and sleeps in wait_for_completion() before
calling virtio_can_napi_enable():

drivers/net/can/virtio_can.c:virtio_can_open() {
	...
	err = virtio_can_start(ndev);
	if (err) {
		close_candev(ndev);
		return err;
	}

	virtio_can_napi_enable(priv);
}

drivers/net/can/virtio_can.c:virtio_can_rx_intr() {
	struct virtio_can_priv *can_priv = vq->vdev->priv;

	virtqueue_disable_cb(vq);
	napi_schedule(&can_priv->napi);
}

CPU0                              CPU1 (virtio interrupt)
virtio_can_restore() / probe()
  virtio_device_ready(vdev)
  virtio_can_populate_rx_vq(vdev)
  virtio_can_open()
    virtio_can_start()
      ...
      wait_for_completion()
                                  virtio_can_rx_intr()
                                    virtqueue_disable_cb(vq)
                                    napi_schedule(&can_priv->napi)
                                      <no-op: NAPI_STATE_SCHED set>
    virtio_can_napi_enable()
      napi_enable(&priv->napi)    <-- clears NAPI_STATE_SCHED;
                                      vq cb stays disabled

Once napi_enable() clears NAPI_STATE_SCHED without scheduling a poll or
re-enabling the virtqueue callback, virtio_can_rx_poll() never runs and RX
is permanently stalled.

Enabling NAPI before virtio_can_start(), or kicking the virtqueues via
virtqueue_napi_schedule() after napi_enable() as virtio-net does in
virtnet_napi_do_enable(), would avoid losing the notification.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-virtio-can-ready-v1-1-0b4dd020af0b@naver.com?part=1