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 v22 04/13] ALSA: pcm: notify drivers after linked prepare completes
Date: Mon, 09 Nov 2026 05:30:09 +0000	[thread overview]
Message-ID: <sashiko-outbox-204440@kernel.org> (raw)
In-Reply-To: <20261109051618.22506-5-mynameisjune111@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ALSA: pcm: spurious MSTOP timer notification in
  snd_pcm_complete_prepare()
- [Medium] ALSA: pcm: race window between snd_pcm_post_prepare() and
  prepare_complete()
--

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

ALSA: pcm: notify drivers after linked prepare completes

This commit adds an optional prepare_complete callback to struct
snd_pcm_ops and invokes it under the PCM stream lock after single or
linked prepare actions complete or fail.

> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index e4c2fe70fa705..40ac7fb614567 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c

[ ... ]

> @@ -1350,6 +1352,13 @@ static int snd_pcm_action_group(const struct action_ops *ops,
>  					ops->undo_action(s1, state);
>  				}
>  			}
> +			if (ops->complete_action) {
> +				snd_pcm_group_for_each_entry(s1, substream) {
> +					ops->complete_action(s1, state, false);
> +					if (s1 == s)
> +						break;
> +				}
> +			}
>  			s = NULL; /* unlock all */
>  			goto _unlock;
>  		}
> @@ -1357,6 +1366,10 @@ static int snd_pcm_action_group(const struct action_ops *ops,
>  	snd_pcm_group_for_each_entry(s, substream) {
>  		ops->post_action(s, state);
>  	}
> +	if (ops->complete_action) {
> +		snd_pcm_group_for_each_entry(s, substream)
> +			ops->complete_action(s, state, true);
> +	}

[Severity: Medium]
Can another caller observe SNDRV_PCM_STATE_PREPARED and invoke ops->ack()
or ops->trigger() in the unlocked window between snd_pcm_post_prepare()
and snd_pcm_complete_prepare()?

snd_pcm_post_prepare() calls snd_pcm_set_state(), which acquires
pcm_stream_lock_irq(substream), publishes SNDRV_PCM_STATE_PREPARED, and
unlocks before snd_pcm_complete_prepare() re-acquires the stream lock to
call ops->prepare_complete().

CPU0                              CPU1
snd_pcm_prepare()
  ...
  snd_pcm_post_prepare(s)
    snd_pcm_set_state(s, PREPARED)
      lock(s)
      __snd_pcm_set_state(s, PREPARED)
      unlock(s)
                                  snd_pcm_common_ioctl()
                                    snd_pcm_sync_ptr(s)
                                      lock(s)
                                      pcm_lib_apply_appl_ptr(s)
                                        s->ops->ack(s)  <-- rejected
  snd_pcm_complete_prepare(s, true)
    lock(s)
    s->ops->prepare_complete(s, true)
    unlock(s)

Because the driver still has admission closed until prepare_complete()
runs, concurrent SNDRV_PCM_IOCTL_SYNC_PTR or SNDRV_PCM_IOCTL_START calls
seeing SNDRV_PCM_STATE_PREPARED can fail with -EBADFD.  In addition, if a
concurrent snd_pcm_drop(), snd_pcm_drain(), or snd_pcm_suspend_all()
changes runtime->state during the unlocked window,
snd_pcm_complete_prepare() still calls prepare_complete(substream, true)
on success, or overwrites SNDRV_PCM_STATE_SUSPENDED with
SNDRV_PCM_STATE_SETUP on failure.

[ ... ]

> @@ -2099,10 +2118,29 @@ static void snd_pcm_post_prepare(struct snd_pcm_substream *substream,
>  	snd_pcm_set_state(substream, SNDRV_PCM_STATE_PREPARED);
>  }
>  
> +static void snd_pcm_complete_prepare(struct snd_pcm_substream *substream,
> +				     snd_pcm_state_t state, bool success)
> +{
> +	if (!substream->ops->prepare_complete)
> +		return;
> +
> +	guard(pcm_stream_lock_irq)(substream);
> +	if (!success && substream->runtime->state != SNDRV_PCM_STATE_DISCONNECTED) {
> +		if (substream->runtime->state != SNDRV_PCM_STATE_SETUP) {
> +			__snd_pcm_set_state(substream->runtime, SNDRV_PCM_STATE_SETUP);
> +			snd_pcm_timer_notify(substream, SNDRV_TIMER_EVENT_MSTOP);
> +		}

[Severity: Medium]
Does snd_pcm_complete_prepare() emit a spurious SNDRV_TIMER_EVENT_MSTOP
notification when prepare fails?

In snd_pcm_prepare(), PAUSED and SUSPENDED streams are already stopped
via snd_pcm_stop() before snd_pcm_action_prepare runs, and
snd_pcm_pre_prepare() rejects RUNNING and playback DRAINING streams with
-EBUSY.  Any substream reaching this path with runtime->state !=
SNDRV_PCM_STATE_SETUP (such as a re-prepare from PREPARED, XRUN, or
capture DRAINING) does not have an active master timer, so calling
snd_pcm_timer_notify(substream, SNDRV_TIMER_EVENT_MSTOP) delivers a
master-stop event with a zero or stale runtime->trigger_tstamp to attached
slave timers.

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

  reply	other threads:[~2026-11-09  5:30 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 23:54 [PATCH v21 00/12] ALSA: virtio: fix capture accounting Joonho Lee
2026-11-08 23:54 ` [PATCH v21 01/12] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-09  0:01   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 02/12] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-09  0:02   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 03/12] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-09  0:05   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 04/12] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-11-09  0:28   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 05/12] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-09  0:24   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 06/12] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-09  0:16   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 07/12] ALSA: virtio: validate indirect capture appl_ptr accounting Joonho Lee
2026-11-09  0:26   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 08/12] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-09  0:04   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 09/12] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-09  0:17   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 10/12] ALSA: virtio: gate starts during PCM prepare Joonho Lee
2026-11-09  0:34   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 11/12] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-11-09  0:07   ` sashiko-bot
2026-11-08 23:54 ` [PATCH v21 12/12] docs: describe virtio-sound capture options Joonho Lee
2026-11-09  0:11   ` sashiko-bot
2026-11-09  5:16 ` [PATCH v22 00/13] ALSA: virtio: validate PCM ACK and prepare completion Joonho Lee
2026-11-09  5:16   ` [PATCH v22 01/13] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-09  5:21     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 02/13] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-09  5:21     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 03/13] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-09  5:25     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 04/13] ALSA: pcm: notify drivers after linked prepare completes Joonho Lee
2026-11-09  5:30     ` sashiko-bot [this message]
2026-11-09  5:16   ` [PATCH v22 05/13] ALSA: virtio: propagate PCM send failures through ACK Joonho Lee
2026-11-09  5:42     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 06/13] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-09  5:42     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 07/13] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-09  5:48     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 08/13] ALSA: virtio: validate indirect PCM ACK accounting Joonho Lee
2026-11-09  5:51     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 09/13] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-09  5:25     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 10/13] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-09  5:30     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 11/13] ALSA: virtio: gate starts during PCM prepare Joonho Lee
2026-11-09  5:54     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 12/13] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-11-09  5:28     ` sashiko-bot
2026-11-09  5:16   ` [PATCH v22 13/13] docs: describe virtio-sound capture options Joonho Lee
2026-11-09  5:29     ` 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-204440@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.