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 v23 09/14] ALSA: virtio: bound PCM transfers and retain DMA buffers
Date: Tue, 10 Nov 2026 00:20:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-205838@kernel.org> (raw)
In-Reply-To: <20261109234049.79534-10-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] ALSA: virtio: partial RX on stop latches XRUN in
virtsnd_pcm_msg_complete()
--
commit 8701e733a8297edcfeb307fc6817693d437f58dc
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: bound PCM transfers and retain DMA buffers
This commit validates PCM buffer geometry, ACK transfer bounds, and RX
completions while retaining backing DMA pages until virtqueue messages are
freed.
> diff --git a/sound/virtio/virtio_pcm_msg.c b/sound/virtio/virtio_pcm_msg.c
> index 59ad99e21e899..c728e8fafb37f 100644
> --- a/sound/virtio/virtio_pcm_msg.c
> +++ b/sound/virtio/virtio_pcm_msg.c
[ ... ]
> @@ -356,42 +536,81 @@ static void virtsnd_pcm_msg_complete(struct virtio_pcm_msg *msg,
> size_t written_bytes)
> {
> struct virtio_pcm_substream *vss = msg->substream;
> + bool capture_invalid = false;
>
> /*
> - * hw_ptr always indicates the buffer position of the first I/O message
> - * in the virtqueue. Therefore, on each completion of an I/O message,
> - * the hw_ptr value is unconditionally advanced.
> + * Completed requests can return captured data after STOP while the PCM
> + * buffer remains prepared. Once preparation ends, completions only retire
> + * queue ownership.
> */
> guard(spinlock)(&vss->lock);
> - /*
> - * If the capture substream returned an incorrect status, then just
> - * increase the hw_ptr by the message size.
> - */
> - if (vss->direction == SNDRV_PCM_STREAM_PLAYBACK ||
> - written_bytes <= sizeof(msg->status))
> - vss->hw_ptr += msg->length;
> - else
> - vss->hw_ptr += written_bytes - sizeof(msg->status);
> + if (vss->direction == SNDRV_PCM_STREAM_CAPTURE &&
> + (!vss->prepared || vss->xfer_xrun ||
> + (vss->stopped && written_bytes <= sizeof(msg->status)))) {
> + msg->length = 0;
> + vss->msg_count--;
> + if (!vss->msg_count)
> + wake_up_all(&vss->msg_empty);
> + return;
> + }
>
> - if (vss->hw_ptr >= vss->buffer_bytes)
> - vss->hw_ptr -= vss->buffer_bytes;
> + /* Only the next complete ring slice can extend captured data. */
> + if (vss->direction == SNDRV_PCM_STREAM_CAPTURE &&
> + (msg->data_offset != vss->hw_ptr ||
> + written_bytes < sizeof(msg->status) ||
> + le32_to_cpu(msg->status.status) != VIRTIO_SND_S_OK ||
> + written_bytes - sizeof(msg->status) != msg->length)) {
> + dev_err_ratelimited(&vss->snd->vdev->dev,
> + "SID %u: invalid capture position, status or length\n",
> + vss->sid);
> + vss->xfer_xrun = true;
> + capture_invalid = true;
> + }
[Severity: Medium]
Does this latch vss->xfer_xrun when the device completes a partially filled RX
buffer upon VIRTIO_SND_R_PCM_STOP?
Under the VirtIO Sound specification (section 5.14.6.8.2.1), the last RX
buffer returned when a capture stream stops may contain fewer than
period_bytes of PCM frames. During SNDRV_PCM_IOCTL_DRAIN,
virtsnd_pcm_trigger(SNDRV_PCM_TRIGGER_STOP) sets vss->stopped = true and sends
VIRTIO_SND_R_PCM_STOP while leaving the substream in SNDRV_PCM_STATE_DRAINING.
A partial RX completion has written_bytes > sizeof(msg->status) and
written_bytes - sizeof(msg->status) < msg->length, so it bypasses the early
return and sets vss->xfer_xrun = true. That causes virtsnd_pcm_cp_ack() to
fail with -EBADFD and virtsnd_pcm_cp_pointer() to report SNDRV_PCM_POS_XRUN,
preventing userspace from draining full periods that had already completed
before STOP.
Similarly, SNDRV_PCM_TRIGGER_PAUSE_PUSH sends VIRTIO_SND_R_PCM_STOP without
setting vss->stopped, so any empty or partial in-flight RX buffer returned on
pause also latches vss->xfer_xrun.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109234049.79534-1-mynameisjune111@gmail.com?part=9
next prev parent reply other threads:[~2026-11-10 0:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 23:40 [PATCH v23 00/14] ALSA: virtio: serialize PCM recovery and capture accounting Joonho Lee
2026-11-09 23:40 ` [PATCH v23 01/14] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-09 23:45 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 02/14] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-09 23:46 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 03/14] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-09 23:48 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 04/14] ALSA: pcm: notify drivers after linked prepare completes Joonho Lee
2026-11-10 0:01 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 05/14] ALSA: pcm: serialize linked buffer actions Joonho Lee
2026-11-09 23:51 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 06/14] ALSA: virtio: propagate PCM send failures through ACK Joonho Lee
2026-11-10 0:07 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 07/14] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-10 0:10 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 08/14] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-10 0:02 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 09/14] ALSA: virtio: bound PCM transfers and retain DMA buffers Joonho Lee
2026-11-10 0:20 ` sashiko-bot [this message]
2026-11-09 23:40 ` [PATCH v23 10/14] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-09 23:51 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 11/14] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-09 23:58 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 12/14] ALSA: virtio: add opt-in staged capture and recovery Joonho Lee
2026-11-10 0:11 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 13/14] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-11-09 23:55 ` sashiko-bot
2026-11-09 23:40 ` [PATCH v23 14/14] docs: describe virtio-sound capture options Joonho Lee
2026-11-09 23:53 ` 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-205838@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.