From: Takashi Iwai <tiwai@suse.de>
To: A Akhil <akhilarul324@gmail.com>
Cc: tiwai@suse.com, perex@perex.cz, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: Sound/seq: hung task in odev_open - unuse callback sleeps under list_mutex
Date: Thu, 17 Sep 2026 13:07:06 +0200 [thread overview]
Message-ID: <87zexggmqt.wl-tiwai@suse.de> (raw)
In-Reply-To: <CACygGA9s1oWO53NPamL5tkaNhUt-W8S736OVAJZcYCU_UOni+A@mail.gmail.com>
On Thu, 17 Sep 2026 04:41:31 +0200,
A Akhil wrote:
>
>
> To: tiwai@suse.com, perex@perex.cz
> Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
> syzkaller-bugs@googlegroups.com
> Subject: sound/seq: hung task in odev_open - unuse callback sleeps under
> list_mutex
>
> Hi,
>
> I've been looking at this syzbot report:
>
> INFO: task hung in odev_open (5)
> https://syzkaller.appspot.com/bug?extid=825b7e3a03dd072c187f
>
> The hang isn't really in the OSS code where it gets reported. syzbot only
> shows the task waiting on register_mutex in odev_open(); the one actually
> holding things up is this:
>
> odev_release takes register_mutex
> snd_seq_oss_release / snd_seq_oss_reset
> snd_seq_oss_synth_reset
> snd_seq_oss_midi_close takes mdev->open_mutex
> snd_seq_ioctl_unsubscribe_port
> snd_seq_port_disconnect
> __delete_and_unsubscribe_port called with grp->list_mutex held
> midisynth_unuse seq_midi.c:298
> snd_rawmidi_drain_output sleeps 10*HZ per substream
> schedule_timeout
>
> delete_and_unsubscribe_port() holds grp->list_mutex for write while the
> unuse callback runs, and midisynth_unuse() ends up in
> snd_rawmidi_drain_output(), which waits 10*HZ per substream. With ~8
> substreams I measured close() taking 82 seconds. Anything calling
> snd_seq_port_connect() blocks on the same rwsem, and in the OSS path that
> connect runs under register_mutex, so every other odev_open() piles up
> behind it and the hung task detector fires.
>
> I tried narrowing register_mutex in odev_release, and then open_mutex in
> snd_seq_oss_midi_close. Both build, both still hang - the wait just moves
> down a level each time, ending up in snd_seq_port_connect().
>
> Moving unsubscribe_port() out of the rwsem looked wrong to me: grp->count
> is protected by it, and the comment above subscribe_port() says open and
> close are only invoked on the 0->1 and 1->0 transitions. If close ran
> unlocked, a concurrent subscribe could call open first.
>
> That pairing also means an opener of the same port has to wait for a close
> in progress anyway, so I don't think lock narrowing can fix this - the
> teardown just has to stop taking tens of seconds.
>
> So the drain has to stop blocking the teardown. I can see three ways to do
> that, but all of them change when or whether pending MIDI output gets
> flushed, and that's not something I want to decide on my own:
>
> - drop the output instead of draining it in midisynth_unuse()
> - move the drain to a workqueue so the unuse callback doesn't sleep
> - keep draining but cap the total wait
>
> Which of those would you take? I can write it and test it.
>
> (v7.3-rc3, 9b87fdc9af2f, qemu with dummy_hcd + raw-gadget. The syz repro
> alone didn't trigger it for me - I needed a second thread opening
> /dev/sequencer2 while another one closes it. That hits the hang in under a
> minute.)
IIUC, this is no real "hang" that locks up forever but just went over
threshold in mutex? If so, we can avoid taking too long mutex like
the (totally untested) patch below?
thanks,
Takashi
-- 8< --
diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
index 2835576040ed..c790b1cd451a 100644
--- a/sound/core/seq/oss/seq_oss.c
+++ b/sound/core/seq/oss/seq_oss.c
@@ -132,13 +132,19 @@ static int
odev_release(struct inode *inode, struct file *file)
{
struct seq_oss_devinfo *dp;
+ int index;
dp = file->private_data;
if (!dp)
return 0;
- guard(mutex)(®ister_mutex);
+ scoped_guard(mutex, ®ister_mutex)
+ snd_seq_oss_detach(dp);
+ index = dp->index;
snd_seq_oss_release(dp);
+ scoped_guard(mutex, ®ister_mutex)
+ snd_seq_oss_detach_done(index);
+
return 0;
}
@@ -149,6 +155,8 @@ odev_read(struct file *file, char __user *buf, size_t count, loff_t *offset)
dp = file->private_data;
if (snd_BUG_ON(!dp))
return -ENXIO;
+ if (dp->closing)
+ return -EBADFD;
return snd_seq_oss_read(dp, buf, count);
}
@@ -160,6 +168,8 @@ odev_write(struct file *file, const char __user *buf, size_t count, loff_t *offs
dp = file->private_data;
if (snd_BUG_ON(!dp))
return -ENXIO;
+ if (dp->closing)
+ return -EBADFD;
return snd_seq_oss_write(dp, buf, count, file);
}
diff --git a/sound/core/seq/oss/seq_oss_device.h b/sound/core/seq/oss/seq_oss_device.h
index 935cf3df0b30..ee318ea1a096 100644
--- a/sound/core/seq/oss/seq_oss_device.h
+++ b/sound/core/seq/oss/seq_oss_device.h
@@ -72,6 +72,7 @@ struct seq_oss_devinfo {
int cseq; /* sequencer client number */
int port; /* sequencer port number */
int queue; /* sequencer queue number */
+ bool closing;
struct snd_seq_addr addr; /* address of this device */
@@ -107,7 +108,9 @@ int snd_seq_oss_delete_client(void);
/* device file interface */
int snd_seq_oss_open(struct file *file, int level);
+void snd_seq_oss_detach(struct seq_oss_devinfo *dp);
void snd_seq_oss_release(struct seq_oss_devinfo *dp);
+void snd_seq_oss_detach_done(int index);
int snd_seq_oss_ioctl(struct seq_oss_devinfo *dp, unsigned int cmd, unsigned long arg);
int snd_seq_oss_read(struct seq_oss_devinfo *dev, char __user *buf, int count);
int snd_seq_oss_write(struct seq_oss_devinfo *dp, const char __user *buf, int count, struct file *opt);
diff --git a/sound/core/seq/oss/seq_oss_init.c b/sound/core/seq/oss/seq_oss_init.c
index 6586e07431c3..3aece0d2981a 100644
--- a/sound/core/seq/oss/seq_oss_init.c
+++ b/sound/core/seq/oss/seq_oss_init.c
@@ -33,6 +33,7 @@ static int system_port __ro_after_init = -1;
static int num_clients;
static struct seq_oss_devinfo *client_table[SNDRV_SEQ_OSS_MAX_CLIENTS];
+#define SEQ_OSS_DETACHED ((struct seq_oss_devinfo *)-1)
/*
* prototypes
@@ -396,14 +397,23 @@ free_devinfo(void *private)
/*
* close sequencer device
*/
+void snd_seq_oss_detach(struct seq_oss_devinfo *dp)
+{
+ dp->closing = true;
+ client_table[dp->index] = SEQ_OSS_DETACHED;
+ num_clients--;
+}
+
+void snd_seq_oss_detach_done(int index)
+{
+ client_table[index] = NULL;
+}
+
void
snd_seq_oss_release(struct seq_oss_devinfo *dp)
{
int queue;
- client_table[dp->index] = NULL;
- num_clients--;
-
snd_seq_oss_reset(dp);
snd_seq_oss_synth_cleanup(dp);
@@ -475,7 +485,7 @@ snd_seq_oss_system_info_read(struct snd_info_buffer *buf)
for (i = 0; i < num_clients; i++) {
snd_iprintf(buf, "\nApplication %d: ", i);
dp = client_table[i];
- if (!dp) {
+ if (!dp || dp == SEQ_OSS_DETACHED) {
snd_iprintf(buf, "*empty*\n");
continue;
}
diff --git a/sound/core/seq/oss/seq_oss_ioctl.c b/sound/core/seq/oss/seq_oss_ioctl.c
index f1a79776773f..2b4930a56a22 100644
--- a/sound/core/seq/oss/seq_oss_ioctl.c
+++ b/sound/core/seq/oss/seq_oss_ioctl.c
@@ -66,6 +66,9 @@ snd_seq_oss_ioctl(struct seq_oss_devinfo *dp, unsigned int cmd, unsigned long ca
void __user *arg = (void __user *)carg;
int __user *p = arg;
+ if (dp->closing)
+ return -EBADFD;
+
switch (cmd) {
case SNDCTL_TMR_TIMEBASE:
case SNDCTL_TMR_TEMPO:
next parent reply other threads:[~2026-09-17 11:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACygGA9s1oWO53NPamL5tkaNhUt-W8S736OVAJZcYCU_UOni+A@mail.gmail.com>
2026-09-17 11:07 ` Takashi Iwai [this message]
2026-09-17 14:11 ` A Akhil
2026-09-17 14:55 ` Takashi Iwai
2026-09-17 15:42 ` A Akhil
2026-09-17 16:13 ` 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=87zexggmqt.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=akhilarul324@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tiwai@suse.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
all inboxes | Powered by JetHome®