From: 임성현 <forfortuna@naver.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Harald Mommer" <harald.mommer@oss.qualcomm.com>,
"Matias Ezequiel Vara Larsen" <mvaralar@redhat.com>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Vincent Mailhol" <mailhol@kernel.org>,
"Mikhail Golubev-Ciuchea"
<mikhail.golubev-ciuchea@oss.qualcomm.com>,
"Francesco Valla" <francesco@valla.it>,
virtualization@lists.linux.dev, linux-can@vger.kernel.org,
linux-kernel@vger.kernel.org, "Jason Wang" <jasowangio@gmail.com>
Subject: Re: [PATCH] can: virtio: fix virtqueue use before DRIVER_OK
Date: Wed, 11 Nov 2026 09:11:05 +0900 [thread overview]
Message-ID: <f439b7997e31bf938812e27bb02a2762@cweb013.nm> (raw)
In-Reply-To: <20261110122457-mutt-send-email-mst@kernel.org>
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
next prev parent reply other threads:[~2026-11-11 0:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 17:11 [PATCH] can: virtio: fix virtqueue use before DRIVER_OK Seonghyeon Lim
2026-11-10 17:11 ` Seonghyeon Lim via B4 Relay
2026-11-10 17:26 ` Michael S. Tsirkin
2026-11-11 0:11 ` 임성현 [this message]
2026-11-10 17:46 ` sashiko-bot
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=f439b7997e31bf938812e27bb02a2762@cweb013.nm \
--to=forfortuna@naver.com \
--cc=francesco@valla.it \
--cc=harald.mommer@oss.qualcomm.com \
--cc=jasowangio@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mikhail.golubev-ciuchea@oss.qualcomm.com \
--cc=mkl@pengutronix.de \
--cc=mst@redhat.com \
--cc=mvaralar@redhat.com \
--cc=virtualization@lists.linux.dev \
/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 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.