From: sashiko-bot@kernel.org
To: "Joonho Lee" <mynameisjune111@gmail.com>
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v1 1/5] ALSA: virtio: Notify queued PCM messages after send errors
Date: Tue, 13 Oct 2026 05:40:29 +0000 [thread overview]
Message-ID: <sashiko-outbox-169002@kernel.org> (raw)
In-Reply-To: <01fd635f9ccd48594864e6e3858389060cdf2aa2.1791867377.git.mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] alsa: virtio: state desync on msg send failure
--
commit e0fc1ff7e6c503fbe54480dc784a6aac80eec85b
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: Notify queued PCM messages after send errors
virtsnd_pcm_msg_send() advances a message length before adding it to
the virtqueue. If a later add fails, the error path returns without
restoring that length or notifying the device about earlier messages
added by the same call. The device can therefore leave successfully
queued messages unprocessed, while the failed message appears
already submitted.
> diff --git a/sound/virtio/virtio_pcm_msg.c b/sound/virtio/virtio_pcm_msg.c
> index 72103f6067169..5371f4985fd06 100644
> --- a/sound/virtio/virtio_pcm_msg.c
> +++ b/sound/virtio/virtio_pcm_msg.c
> @@ -260,6 +260,18 @@ int virtsnd_pcm_msg_send(struct virtio_pcm_substream *vss, unsigned long offset,
> dev_err(&vdev->dev,
> "SID %u: failed to send I/O message\n",
> vss->sid);
> + msg->length -= n;
[Severity: High]
Does this length rollback desynchronize the virtio message state from the ALSA
indirect layer?
When virtsnd_pcm_msg_send() fails and returns an error, its caller,
virtsnd_pcm_trans_copy(), ignores the return value:
sound/virtio/virtio_pcm_ops.c:virtsnd_pcm_trans_copy() {
struct virtio_pcm_substream *vss = snd_pcm_substream_chip(substream);
virtsnd_pcm_msg_send(vss, rec->sw_data, bytes);
}
Because virtsnd_pcm_trans_copy() returns void, the ALSA indirect layer
(snd_pcm_indirect_playback_transfer()) assumes success and unconditionally
advances its software offset pointers.
Since the ALSA pointer advanced but the virtio message length rolled back, the
two states become out of sync. On the next wrap-around, will the skipped
message artificially reach period_bytes with old/new mixed data and be
submitted to the virtqueue out of order?
Should the driver set substream->runtime->stop_operating = true inside
virtsnd_pcm_msg_send() to properly abort the stream when an I/O message
fails?
> +
> + /*
> + * Do not leave earlier messages queued without notifying
> + * the device when a later message could not be added.
> + */
> + if (msg_count != vss->msg_count &&
> + !(vss->features &
> + (1U << VIRTIO_SND_PCM_F_MSG_POLLING)) &&
> + virtqueue_kick_prepare(vqueue))
> + virtqueue_notify(vqueue);
> +
> return rc;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791867377.git.mynameisjune111@gmail.com?part=1
next prev parent reply other threads:[~2026-10-13 5:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 5:30 [PATCH v1 0/5] ALSA: virtio: Fix request lifetime and error recovery Joonho Lee
2026-10-13 5:30 ` [PATCH v1 1/5] ALSA: virtio: Notify queued PCM messages after send errors Joonho Lee
2026-10-13 5:40 ` sashiko-bot [this message]
2026-10-13 5:30 ` [PATCH v1 2/5] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-10-13 5:42 ` sashiko-bot
2026-10-13 5:30 ` [PATCH v1 3/5] ALSA: virtio: Retain control requests through device reset Joonho Lee
2026-10-13 5:43 ` sashiko-bot
2026-10-13 5:30 ` [PATCH v1 4/5] ALSA: virtio: Retain PCM DMA pages until messages are freed Joonho Lee
2026-10-13 5:39 ` sashiko-bot
2026-10-13 5:30 ` [PATCH v1 5/5] ALSA: virtio: Keep control payloads in refcounted messages Joonho Lee
2026-10-13 5:39 ` 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-169002@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--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.