Linux Sound subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alexandre Becholey" <alex@becholey.ch>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH 4/5] ALSA: usx2y: us144mkii: wait for the URB completion handlers on stop and close
Date: Sat, 14 Nov 2026 17:59:42 +0000	[thread overview]
Message-ID: <sashiko-outbox-214863@kernel.org> (raw)
In-Reply-To: <20261114172806.88710-5-alex@becholey.ch>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] ALSA: usx2y: us144mkii: missing rcu_assign_pointer() in PCM
  open callbacks
--

commit 6a69f01bf459c14f59000c815994e8cebf887174
Author: Alexandre Becholey <alex@becholey.ch>

ALSA: usx2y: us144mkii: wait for the URB completion handlers on stop and close

This commit protects the playback and capture substream accesses in the
URB completion handlers with RCU read-side critical sections and waits for
grace periods in the PCM .close and .sync_stop callbacks.

> diff --git a/sound/usb/usx2y/us144mkii_playback.c b/sound/usb/usx2y/us144mkii_playback.c
> index e6266488cf325..36d5417d9975a 100644
> --- a/sound/usb/usx2y/us144mkii_playback.c
> +++ b/sound/usb/usx2y/us144mkii_playback.c
[ ... ]
> @@ -180,9 +183,13 @@ void playback_urb_complete(struct urb *urb)
>  	if (!tascam || !atomic_read(&tascam->playback_active))
>  		goto out;
>  
> -	substream = tascam->playback_substream;
> -	if (!substream || !substream->runtime)
> +	/* Pairs with synchronize_rcu() in close and sync_stop. */
> +	rcu_read_lock();
> +	substream = READ_ONCE(tascam->playback_substream);
> +	if (!substream || !substream->runtime) {
> +		rcu_read_unlock();
>  		goto out;
> +	}
>  	runtime = substream->runtime;
[ ... ]
> @@ -295,12 +303,16 @@ void feedback_urb_complete(struct urb *urb)
>  	if (!tascam || !atomic_read(&tascam->playback_active))
>  		goto out;
>  
> -	playback_ss = tascam->playback_substream;
> -	if (!playback_ss || !playback_ss->runtime)
> +	/* Pairs with synchronize_rcu() in close and sync_stop. */
> +	rcu_read_lock();
> +	playback_ss = READ_ONCE(tascam->playback_substream);
> +	if (!playback_ss || !playback_ss->runtime) {
> +		rcu_read_unlock();
>  		goto out;
> +	}
>  	playback_rt = playback_ss->runtime;
>  
> -	capture_ss = tascam->capture_substream;
> +	capture_ss = READ_ONCE(tascam->capture_substream);
>  	capture_rt = capture_ss ? capture_ss->runtime : NULL;

[Severity: Medium]
Can playback_urb_complete() and feedback_urb_complete() observe a non-NULL
playback_substream or capture_substream before substream->runtime and the
newly allocated struct snd_pcm_runtime are initialized?

tascam_playback_open() and tascam_capture_open() publish
tascam->playback_substream and tascam->capture_substream with plain stores
without a release barrier:

sound/usb/usx2y/us144mkii_playback.c:tascam_playback_open() {
	struct tascam_card *tascam = snd_pcm_substream_chip(substream);

	substream->runtime->hw = tascam_pcm_hw;
	tascam->playback_substream = substream;
	atomic_set(&tascam->playback_active, 0);

Because struct snd_pcm_substream is preallocated when the card is created,
there is no address dependency from the runtime allocation in
snd_pcm_attach_substream() to the substream pointer itself.  If one
substream is opened while the other direction already has the URBs running,
the completion handlers on a weakly-ordered CPU can observe the published
substream pointer while seeing either a NULL substream->runtime (causing
playback_urb_complete() or feedback_urb_complete() to bail out without
resubmitting the URB) or stale fields in a reused struct snd_pcm_runtime
before its zero-initialization becomes visible.

Using rcu_assign_pointer() in tascam_playback_open() and
tascam_capture_open() (paired with rcu_dereference() here, and NULLing the
pointers with RCU_INIT_POINTER() in the .close callbacks) would order the
runtime initialization before the substream pointer publication.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114172806.88710-1-alex@becholey.ch?part=4

  reply	other threads:[~2026-11-14 17:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 17:28 [PATCH 0/5] ALSA: usx2y: us144mkii: fix PCM stream lifetime bugs Alexandre Becholey
2026-11-14 17:28 ` [PATCH 1/5] ALSA: usx2y: us144mkii: fix stop_pcm_work race with PCM close Alexandre Becholey
2026-11-14 17:28 ` [PATCH 2/5] ALSA: usx2y: us144mkii: wait for the capture work on capture close Alexandre Becholey
2026-11-14 17:28 ` [PATCH 3/5] ALSA: usx2y: us144mkii: only touch the buffer of a running PCM stream Alexandre Becholey
2026-11-14 17:53   ` sashiko-bot
2026-11-14 17:29 ` [PATCH 4/5] ALSA: usx2y: us144mkii: wait for the URB completion handlers on stop and close Alexandre Becholey
2026-11-14 17:59   ` sashiko-bot [this message]
2026-11-14 17:29 ` [PATCH 5/5] ALSA: usx2y: us144mkii: do not restart the stream while stop_work runs Alexandre Becholey

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-214863@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=alex@becholey.ch \
    --cc=linux-sound@vger.kernel.org \
    --cc=sashiko-reviews@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox