All of lore.kernel.org
 help / color / mirror / Atom feed
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 v16 10/12] ALSA: virtio: add staged capture and serialize PCM lifecycle accounting
Date: Thu, 05 Nov 2026 02:59:04 +0000	[thread overview]
Message-ID: <sashiko-outbox-198493@kernel.org> (raw)
In-Reply-To: <20261105023140.18373-11-mynameisjune111@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: virtio: virtsnd_pcm_period_elapsed() corrupts linked paused streams
--

commit d8e5fc87d68c2238eeb8bbf2e3deb7ce9fbe8f3e
Author: Joonho Lee <mynameisjune111@gmail.com>

ALSA: virtio: add staged capture and serialize PCM lifecycle accounting

This commit adds staged capture using request-owned RX storage and
separates produced, observed, and consumed positions for shared capture
clients. It also serializes PCM lifecycle operations with lifecycle_lock
and ACK accounting with the PCM stream lock.

> diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
> index be3893de40a55..f9b301e4a70ae 100644
> --- a/sound/virtio/virtio_pcm.c
> +++ b/sound/virtio/virtio_pcm.c
> @@ -310,8 +310,119 @@ static void virtsnd_pcm_period_elapsed(struct work_struct *work)
>  {
>  	struct virtio_pcm_substream *vss =
>  		container_of(work, struct virtio_pcm_substream, elapsed_period);
> +	struct snd_pcm_substream *substream = vss->substream;
> +	struct snd_pcm_runtime *runtime;
> +	size_t period_bytes;
> +	u64 period_floor;
> +	u64 snapshot;
> +	bool staged_capture;
> +	bool paused_xrun = false;
> +	bool notify = false;
> +	bool partial = false;
> +	bool requeue = false;
> +
> +	scoped_guard(spinlock_irqsave, &vss->lock) {
> +		staged_capture = vss->direction == SNDRV_PCM_STREAM_CAPTURE &&
> +				 vss->capture_staging;
> +	}
> +
> +	/* Serialize the pointer snapshot with ALSA's pointer and ACK callbacks. */
> +	guard(pcm_stream_lock_irqsave)(substream);
> +	if (!substream->runtime)
> +		return;
> +	if (!snd_pcm_running(substream)) {
> +		scoped_guard(spinlock_irqsave, &vss->lock) {
> +			runtime = substream->runtime;
> +			paused_xrun = runtime &&
> +				      runtime->state == SNDRV_PCM_STATE_PAUSED &&
> +				      vss->xfer_xrun;
> +			if (paused_xrun)
> +				virtsnd_pcm_capture_arm_paused_stop(vss);
> +		}
> +		if (paused_xrun) {
> +			/* Stop paused transfers and wake blocked readers. */
> +			snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
> +		}
> +		return;
> +	}

[Severity: High]
How does virtsnd_pcm_period_elapsed() handle paused substreams that are
linked to sibling substreams via SNDRV_PCM_IOCTL_LINK?

When runtime->state is SNDRV_PCM_STATE_PAUSED and vss->xfer_xrun is set,
virtsnd_pcm_period_elapsed() calls virtsnd_pcm_capture_arm_paused_stop(vss)
on only that single substream (setting vss->xfer_enabled = false,
vss->stopped = true, and runtime->stop_operating = true), and then calls
snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN).

Because snd_pcm_stop() runs snd_pcm_action(&snd_pcm_action_stop, ...)
across all substreams in substream->group, and snd_pcm_do_stop() only
invokes ops->trigger(s, SNDRV_PCM_TRIGGER_STOP) and sets
s->runtime->stop_operating = true when snd_pcm_running(s) is true (which is
false for SNDRV_PCM_STATE_PAUSED), snd_pcm_post_stop() transitions any
paused sibling substream to SNDRV_PCM_STATE_XRUN without
virtsnd_pcm_capture_arm_paused_stop() ever running on it.

When userspace subsequently calls SNDRV_PCM_IOCTL_DROP, snd_pcm_drop() sees
the sibling substream already in SNDRV_PCM_STATE_XRUN rather than
SNDRV_PCM_STATE_PAUSED, so snd_pcm_pause(s, false) and snd_pcm_do_stop()
are skipped, and snd_pcm_sync_stop() is also skipped because
s->runtime->stop_operating is false. Does this leave the sibling substream
in SNDRV_PCM_STATE_SETUP while its VirtIO stream remains prepared on the
device with active virtqueue buffers?

In addition, if substream is linked and snd_pcm_stream_group_ref() inside
snd_pcm_stop() contends on group->mutex, it temporarily drops substream's
PCM stream lock to acquire group->mutex in lock order. Can a concurrent
snd_pcm_drop() or snd_pcm_prepare() complete during that window and place
the substreams into SNDRV_PCM_STATE_SETUP or a new SNDRV_PCM_STATE_PREPARED
epoch before snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN) finishes locking
and overwrites runtime->state with SNDRV_PCM_STATE_XRUN?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105023140.18373-1-mynameisjune111@gmail.com?part=10

  reply	other threads:[~2026-11-05  2:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  2:31 [PATCH v16 00/12] ALSA: virtio: fix capture lifetime and accounting Joonho Lee
2026-11-05  2:31 ` [PATCH v16 01/12] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-05  2:35   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 02/12] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-05  2:36   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 03/12] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-05  2:40   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 04/12] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-11-05  3:07   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 05/12] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-05  2:57   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 06/12] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-05  3:02   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 07/12] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-11-05  2:56   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 08/12] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-05  2:39   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 09/12] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-05  2:50   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 10/12] ALSA: virtio: add staged capture and serialize PCM lifecycle accounting Joonho Lee
2026-11-05  2:59   ` sashiko-bot [this message]
2026-11-05  2:31 ` [PATCH v16 11/12] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-11-05  2:44   ` sashiko-bot
2026-11-05  2:31 ` [PATCH v16 12/12] docs: describe virtio-sound capture options Joonho Lee
2026-11-05  2:43   ` 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-198493@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.