From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "Harald Mommer" <harald.mommer@oss.qualcomm.com>,
"Vincent Mailhol" <mailhol@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
linux-can@vger.kernel.org, virtualization@lists.linux.dev,
"Mikhail Golubev-Ciuchea"
<mikhail.golubev-ciuchea@oss.qualcomm.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
francesco@valla.it
Subject: Re: [PATCH v13] can: virtio: Add virtio CAN driver
Date: Tue, 7 Apr 2026 15:48:48 +0200 [thread overview]
Message-ID: <adULQMZggR9M/Fgx@fedora> (raw)
In-Reply-To: <acLNB9PYmJ9L0Wvc@fedora>
On Tue, Mar 24, 2026 at 06:42:31PM +0100, Matias Ezequiel Vara Larsen wrote:
> On Mon, Mar 23, 2026 at 11:36:18AM +0100, Marc Kleine-Budde wrote:
> > Hello,
> >
>
> Hello and thanks, I am struggling to come up with a solution for this
> comment.
>
> > The nipa/ai-review bot found these problems:
> >
> > | https://netdev-ai.bots.linux.dev/ai-review.html?id=b046d75a-2de1-4063-bb96-8f64abc65e7d
> >
> > commit 0f3cb3b3bc94eaff9b9709b528e498fe6150f9c1
> > Author: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
> >
> > can: virtio: Add virtio CAN driver
> >
> > This commit adds a virtio CAN driver implementing a complete CAN bus
> > interface over Virtio transport, supporting both CAN Classic and CAN-FD
> > frames.
> >
> > > diff --git a/drivers/net/can/virtio_can.c b/drivers/net/can/virtio_can.c
> > > new file mode 100644
> > > index 000000000000..57641c3ed6d0
> > > --- /dev/null
> > > +++ b/drivers/net/can/virtio_can.c
> >
> > [ ... ]
> >
> > > +static int __maybe_unused virtio_can_restore(struct virtio_device *vdev)
> > > +{
> > > + struct virtio_can_priv *priv = vdev->priv;
> > > + struct net_device *ndev = priv->dev;
> > > + size_t size;
> > > + int err;
> > > +
> > > + napi_enable(&priv->napi);
> > > + napi_enable(&priv->napi_tx);
> > > +
> > > + err = virtio_can_find_vqs(priv);
> > > + if (err != 0)
> > > + return err;
> >
> > What happens to the enabled NAPI instances when this error path is taken?
> > virtio_can_restore() enables both NAPI instances at the start, but if
> > virtio_can_find_vqs() fails here, the function returns without calling
> > napi_disable().
> >
> I was expecting that, if virtio_can_restore() fails, then a successive
> virtio_can_remove() will not hang in napi_disable() since the napis were
> already enabled.
>
Ping @Marc Kleine-Budde, do you have any comment about the comments
above?
Thanks, Matias
> > The corresponding virtio_can_freeze() function disables both NAPIs before
> > returning, so the restore function leaves the NAPI subsystem in an
> > inconsistent state on failure.
> >
> > If the PM framework retries restore after this failure, the second
> > napi_enable() call on an already-enabled NAPI will hit the BUG_ON in
> > napi_enable_locked():
> >
>
> Does the PM framework really retries if virtio_can_restore() fails? If not, that BUG_ON
> is never reached.
>
> > net/core/dev.c:napi_enable_locked() {
> > BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
> > ...
> > }
> >
> > In contrast, virtio_can_probe() enables NAPI only after all setup
> > succeeds, avoiding this issue.
> >
> > > +
> > > + size = priv->rpkt_len * priv->vqs[VIRTIO_CAN_QUEUE_RX]->num_free;
> > > + priv->rpkt = devm_krealloc(&vdev->dev, priv->rpkt, size, GFP_KERNEL | __GFP_ZERO);
> > > + if (!priv->rpkt) {
> > > + virtio_can_del_vq(vdev);
> > > + return -ENOMEM;
> > > + }
> >
> > The same NAPI state issue occurs on this error path.
> >
> > > + virtio_can_populate_rx_vq(vdev);
> > > +
> > > + if (netif_running(ndev)) {
> > > + err = virtio_can_start(ndev);
> > > + if (err) {
> > > + virtio_can_del_vq(vdev);
> > > + return err;
> > > + }
> >
> > And again on this error path.
> >
> > Should all three error paths call napi_disable(&priv->napi_tx) and
> > napi_disable(&priv->napi) before returning the error code?
> >
> > --
> > Pengutronix e.K. | Marc Kleine-Budde |
> > Embedded Linux | https://www.pengutronix.de |
> > Vertretung Nürnberg | Phone: +49-5121-206917-129 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
>
>
prev parent reply other threads:[~2026-04-07 13:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 17:36 [PATCH v13] can: virtio: Add virtio CAN driver Matias Ezequiel Vara Larsen
2026-03-23 10:36 ` Marc Kleine-Budde
2026-03-24 17:42 ` Matias Ezequiel Vara Larsen
2026-04-02 9:52 ` Dorinda Bassey
2026-04-07 8:36 ` Matias Ezequiel Vara Larsen
2026-04-07 13:48 ` Matias Ezequiel Vara Larsen [this message]
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=adULQMZggR9M/Fgx@fedora \
--to=mvaralar@redhat.com \
--cc=eperezma@redhat.com \
--cc=francesco@valla.it \
--cc=harald.mommer@oss.qualcomm.com \
--cc=jasowang@redhat.com \
--cc=linux-can@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mikhail.golubev-ciuchea@oss.qualcomm.com \
--cc=mkl@pengutronix.de \
--cc=mst@redhat.com \
--cc=sgarzare@redhat.com \
--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