From: "Piotr Gliźniewicz" <p.glizniewicz@gmail.com>
To: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>
Cc: "Torsten Schenk" <torsten.schenk@zoho.com>,
linux-sound@vger.kernel.org,
"Piotr Gliźniewicz" <p.glizniewicz@gmail.com>
Subject: [PATCH 1/3] ALSA: 6fire: take stream_mutex in the Digital Thru control
Date: Fri, 16 Oct 2026 09:31:30 +0200 [thread overview]
Message-ID: <20261016073132.109288-2-p.glizniewicz@gmail.com> (raw)
In-Reply-To: <20261016073132.109288-1-p.glizniewicz@gmail.com>
usb6fire_control_digital_thru_put() calls
usb6fire_control_streaming_update(), which on an idle card with Digital
Thru on selects altsetting 2 and writes the clock register for 96 kHz
through usb6fire_control_set_rate(). usb6fire_pcm_prepare() calls both
functions through usb6fire_pcm_set_rate() under rt->stream_mutex. The
put does not take stream_mutex, so the two can run at the same time.
500 runs of a 0.2 s aplay at 48 kHz while a second loop toggled
"Digital Thru Playback Route" with amixer (12693 on/off cycles, kernel
7.2.9): in 216 cases the two usb_set_interface() calls ran at the same
time and the kernel logged "sysfs: cannot create duplicate filename
'.../3-2:1.1/ep_82'" with a stack dump. 27 of the aplay runs failed,
and for each of them the kernel logged "could not start pcm stream".
Take stream_mutex in the put. The pcm runtime is created before the
controls and freed with the card, so chip->pcm is valid whenever the
put runs. The put waits for a running prepare, which makes synchronous
USB transfers under stream_mutex; on a card that responds late the wait
can reach about 12 s, or 24 s with Digital Thru on, and during the wait
the other controls of the card can be neither read nor written, because
snd_ctl_elem_write() holds controls_rwsem around the put. Before this
patch the put already made transfers of the same kind under
controls_rwsem. No code that holds stream_mutex takes controls_rwsem.
The same test on kernel 7.2.10 with this patch (12863 cycles) gave no
failed aplay run and no "duplicate filename" message.
Fixes: 2475b0d40761 ("ALSA: 6fire - Add support of digital-thru mixer")
Assisted-by: LLM
Signed-off-by: Piotr Gliźniewicz <p.glizniewicz@gmail.com>
---
sound/usb/6fire/control.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sound/usb/6fire/control.c b/sound/usb/6fire/control.c
index 10104cb42..020e9676d 100644
--- a/sound/usb/6fire/control.c
+++ b/sound/usb/6fire/control.c
@@ -20,6 +20,7 @@
#include "control.h"
#include "comm.h"
#include "chip.h"
+#include "pcm.h"
static const char * const opt_coax_texts[2] = { "Optical", "Coax" };
static const char * const line_phono_texts[2] = { "Line", "Phono" };
@@ -383,6 +384,12 @@ static int usb6fire_control_digital_thru_put(struct snd_kcontrol *kcontrol,
struct control_runtime *rt = snd_kcontrol_chip(kcontrol);
int changed = 0;
+ /*
+ * with Digital Thru on, streaming_update() selects the altsetting and
+ * writes the clock register of an idle card; prepare does the same
+ * under stream_mutex
+ */
+ guard(mutex)(&rt->chip->pcm->stream_mutex);
if (rt->digital_thru_switch != ucontrol->value.integer.value[0]) {
rt->digital_thru_switch = ucontrol->value.integer.value[0];
usb6fire_control_streaming_update(rt);
--
2.56.0
next prev parent reply other threads:[~2026-10-16 7:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 7:31 [PATCH 0/3] ALSA: 6fire: S/PDIF output Piotr Gliźniewicz
2026-10-16 7:31 ` Piotr Gliźniewicz [this message]
2026-10-16 7:31 ` [PATCH 2/3] ALSA: 6fire: add a playback channel map Piotr Gliźniewicz
2026-10-16 7:31 ` [PATCH 3/3] ALSA: 6fire: add S/PDIF output Piotr Gliźniewicz
2026-10-16 16:46 ` [PATCH 0/3] ALSA: 6fire: " Takashi Iwai
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=20261016073132.109288-2-p.glizniewicz@gmail.com \
--to=p.glizniewicz@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=torsten.schenk@zoho.com \
/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