From: sashiko-bot@kernel.org
To: "Joonho Lee" <mynameisjune111@gmail.com>, linux-sound@vger.kernel.org
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v8 02/14] ALSA: virtio: Recover PCM state after a failed start
Date: Thu, 29 Oct 2026 06:10:32 +0000 [thread overview]
Message-ID: <sashiko-outbox-188795@kernel.org> (raw)
In-Reply-To: <20261029054354.2931-3-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ALSA: virtio: virtsnd_pcm_sync_stop() resends PCM_RELEASE after drain failure
--
commit 8526e884d4c74a3678dceb6e148567c0ca936c95
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: Recover PCM state after a failed start
This patch recovers PCM substream state when a start trigger fails by marking
the stream stopped, disabling transfers, arming stop_operating, and protecting
accesses to the stopped flag with vss->lock.
> diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
> index a40ea394bf174..970499fe419b4 100644
> --- a/sound/virtio/virtio_pcm_ops.c
> +++ b/sound/virtio/virtio_pcm_ops.c
[ ... ]
> @@ -115,7 +124,8 @@ static int virtsnd_pcm_open(struct snd_pcm_substream *substream)
> snd_pcm_hw_constraint_integer(substream->runtime,
> SNDRV_PCM_HW_PARAM_PERIODS);
>
> - vss->stopped = !!virtsnd_pcm_msg_pending_num(vss);
> + scoped_guard(spinlock_irqsave, &vss->lock)
> + vss->stopped |= !!vss->msg_count;
> vss->suspended = false;
[ ... ]
> @@ -393,21 +434,31 @@ static int virtsnd_pcm_sync_stop(struct snd_pcm_substream *substream)
> struct virtio_snd *snd = vss->snd;
> struct virtio_snd_msg *msg;
> unsigned int js = msecs_to_jiffies(virtsnd_msg_timeout_ms);
> + bool need_release;
> int rc;
>
> + scoped_guard(spinlock_irqsave, &vss->lock) {
> + vss->xfer_enabled = false;
> + need_release = vss->stopped || vss->msg_count;
> + if (need_release)
> + vss->stopped = true;
> + }
> cancel_work_sync(&vss->elapsed_period);
> -
> - if (!vss->stopped)
> + if (!need_release)
> return 0;
>
> msg = virtsnd_pcm_ctl_msg_alloc(vss, VIRTIO_SND_R_PCM_RELEASE,
> GFP_KERNEL);
> - if (!msg)
> + if (!msg) {
> + substream->runtime->stop_operating = true;
> return -ENOMEM;
> + }
>
> rc = virtsnd_ctl_msg_send_sync(snd, msg);
> - if (rc)
> + if (rc) {
> + substream->runtime->stop_operating = true;
> return rc;
> + }
>
> /*
> * The spec states that upon receipt of the RELEASE command "the device
> @@ -421,11 +472,13 @@ static int virtsnd_pcm_sync_stop(struct snd_pcm_substream *substream)
> if (rc <= 0) {
> dev_warn(&snd->vdev->dev, "SID %u: failed to flush I/O queue\n",
> vss->sid);
> + substream->runtime->stop_operating = true;
>
> return !rc ? -ETIMEDOUT : rc;
> }
>
> - vss->stopped = false;
> + scoped_guard(spinlock_irqsave, &vss->lock)
> + vss->stopped = false;
>
> return 0;
> }
[Severity: Medium]
Can virtsnd_pcm_sync_stop() send a duplicate VIRTIO_SND_R_PCM_RELEASE command
if the post-release queue drain wait is interrupted or times out?
In virtsnd_pcm_sync_stop(), after virtsnd_ctl_msg_send_sync() succeeds for
VIRTIO_SND_R_PCM_RELEASE, wait_event_interruptible_timeout() waits for
in-flight I/O messages to drain. If a signal is pending or the wait times out
before the last message completes, virtsnd_pcm_sync_stop() sets
substream->runtime->stop_operating = true and returns an error while leaving
vss->stopped = true.
Once the device finishes returning the remaining I/O messages and
vss->msg_count reaches 0, vss->stopped remains true because a single boolean
tracks both whether VIRTIO_SND_R_PCM_RELEASE still needs to be sent and
whether pending I/O messages have finished draining.
Because virtsnd_pcm_open() now uses vss->stopped |= !!vss->msg_count, and
virtsnd_pcm_hw_params() and virtsnd_pcm_prepare() reject the substream with
-EBADFD while vss->stopped is true, the next virtsnd_pcm_sync_stop() call
(during close, hw_free, prepare, hw_params, or reopen via virtsnd_pcm_open())
sees need_release = vss->stopped || vss->msg_count as true and sends a second
VIRTIO_SND_R_PCM_RELEASE command for a stream that was already released. If
the device rejects the duplicate release command, virtsnd_pcm_sync_stop()
fails again and leaves vss->stopped = true, wedging the substream.
Note that a later commit in the series ("ALSA: virtio: add staged capture
accounting and lifecycle recovery") changes the drain wait in
virtsnd_pcm_sync_stop_locked() to wait_event_timeout() and tracks
VIRTSND_PCM_PAUSE_RESTART_RELEASE_SENT in the opt-in pause-restart state
machine, but the default virtsnd_pcm_sync_stop_locked() path still leaves
vss->stopped = true (and vss->prepared = true) if the drain wait times out
after VIRTIO_SND_R_PCM_RELEASE succeeded.
Should the driver track whether VIRTIO_SND_R_PCM_RELEASE has already succeeded
separately from whether vss->msg_count has drained to 0, so a subsequent
virtsnd_pcm_sync_stop() only waits for remaining messages to drain instead of
resending VIRTIO_SND_R_PCM_RELEASE?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029054354.2931-1-mynameisjune111@gmail.com?part=2
next prev parent reply other threads:[~2026-10-29 6:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 5:43 [PATCH v8 00/14] ALSA: virtio: staged capture recovery and PCM RESET synchronization Joonho Lee
2026-10-29 5:43 ` [PATCH v8 01/14] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-10-29 6:06 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 02/14] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-10-29 6:10 ` sashiko-bot [this message]
2026-10-29 5:43 ` [PATCH v8 03/14] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-10-29 6:14 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 04/14] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-10-29 6:07 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 05/14] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-10-29 5:54 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 06/14] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-10-29 6:00 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 07/14] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-10-29 5:48 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 08/14] ALSA: pcm: stop paused streams before synchronizing teardown Joonho Lee
2026-10-29 6:04 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 09/14] ALSA: virtio: add staged capture accounting and lifecycle recovery Joonho Lee
2026-10-29 6:23 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 10/14] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-10-29 5:48 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 11/14] docs: describe virtio-sound capture options Joonho Lee
2026-10-29 5:47 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 12/14] ALSA: pcm: add an optional reset operation under the stream lock Joonho Lee
2026-10-29 5:52 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 13/14] ALSA: virtio: synchronize staged capture reset with PCM positions Joonho Lee
2026-10-29 6:05 ` sashiko-bot
2026-10-29 5:43 ` [PATCH v8 14/14] ALSA: virtio: synchronize indirect capture positions on reset Joonho Lee
2026-10-29 6:06 ` 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=sashiko-outbox-188795@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=linux-sound@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mynameisjune111@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--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.