| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <s5h7ggqyezx.wl%tiwai@suse.de>
Date: Tue, 16 Jul 2013 12:29:38 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Philipp Hahn <pmhahn@...ahn.de>
Cc: Rusty Russell <rusty@...tcorp.com.au>, alsa-devel@...a-project.org,
Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Lucas De Marchi" <lucas.demarchi@...fusion.mobi>
Subject: Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs
At Tue, 16 Jul 2013 10:28:02 +0200,
Philipp Hahn wrote:
>
> Hello,
>
> Am Dienstag 16 Juli 2013, 08:43:36 schrieb Takashi Iwai:
> > At Tue, 16 Jul 2013 15:11:51 +0930, Rusty Russell wrote:
> > > Philipp Matthias Hahn <pmhahn@...ahn.de> writes:
> > > > My x86_64 systems has some trouble loading some ALSA snd-* modules since
> > > > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> > > > loading snd-intel-hda and snd-audio-usb by hand still works.
> > >
> > > Not a known problem to me, at least. Perhaps it's a dep loop somehow.
> >
> > I remember that someone reported it being Debian specific snd-seq-oss
> > loading stuff.
>
> FYI: "oss-compat" is installed.
>
> > > > ...
> > > > 1071 ? S 0:00 sh -c /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet snd
> > > > 1080 ? D 0:00 \_ /sbin/modprobe --quiet snd-seq
> > >
> > > This was first, and it's waiting. Which means it must be doing
> > > something weird, because snd_seq_oss is loading now:
> > >
> > > > snd_seq_oss 33717 1 - Loading 0xffffffffa041b000
> > >
> > > Perhaps in the tangle of modprobe install commands somewhere this gets
> > > invoked?
> >
> > Likely, but I wonder what triggered a bug suddenly on 3.10.
> > There is absolutely no change in sound/core/seq/*, and through a quick
> > look, I couldn't find any suspicious change in kernel/module.c that
> > may lead to this problem between 3.9 and 3.10.
> >
> > Philipp, can you get a sysrq-T trace while the stall?
>
> I've finally been able to reducte the number of processes to get a full trace; see attached file.
>
> Please note that in this case the proprietary "nvidia" module was loaded, since I currently onyl have remove access to the machine.
> The original trace from yesterday happend without the nvidia module ever being loaded.
>
> Am Dienstag 16 Juli 2013, 08:42:35 schrieb Lucas De Marchi:
> > On Tue, Jul 16, 2013 at 2:41 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> > First thing to check is the /etc/modprobe.d/*.conf file that contains
> > these install commands. Did they change besides the kernel upgrade?
>
> Not that I know of: Booting 3.9.9 works fine, 3.10.x shows the problem.
>
> ...
> > Philipp, which kernel are you upgrading from?
> I just upgraded from 3.9.9 to 3.10.0; also tried 3.10.1 which did not improve the situation.
Could you check the patch below? It makes the code path involving
with request_module asynchronous.
thanks,
Takashi
---
From: Takashi Iwai <tiwai@...e.de>
Subject: [PATCH] ALSA: seq-oss: Initialize MIDI clients asynchronously
The recent report showed that the initial registration of OSS
sequencer clients stuck at loading the sound modules, which involves
with request_module() at the init phase. As a workaround, call the
registration part asynchronously. (And, this is a better approache
irrespective of the hang fix.)
Reported-by: Philipp Matthias Hahn <pmhahn@...ahn.de>
Cc: <stable@...r.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@...e.de>
---
sound/core/seq/oss/seq_oss_init.c | 16 +++++++++++++---
sound/core/seq/oss/seq_oss_midi.c | 2 +-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/sound/core/seq/oss/seq_oss_init.c b/sound/core/seq/oss/seq_oss_init.c
index e3cb46f..b3f39b5 100644
--- a/sound/core/seq/oss/seq_oss_init.c
+++ b/sound/core/seq/oss/seq_oss_init.c
@@ -31,6 +31,7 @@
#include <linux/export.h>
#include <linux/moduleparam.h>
#include <linux/slab.h>
+#include <linux/workqueue.h>
/*
* common variables
@@ -60,6 +61,14 @@ static void free_devinfo(void *private);
#define call_ctl(type,rec) snd_seq_kernel_client_ctl(system_client, type, rec)
+/* call snd_seq_oss_midi_lookup_ports() asynchronously */
+static void async_call_lookup_ports(struct work_struct *work)
+{
+ snd_seq_oss_midi_lookup_ports(system_client);
+}
+
+static DECLARE_WORK(async_lookup_work, async_call_lookup_ports);
+
/*
* create sequencer client for OSS sequencer
*/
@@ -85,9 +94,6 @@ snd_seq_oss_create_client(void)
system_client = rc;
debug_printk(("new client = %d\n", rc));
- /* look up midi devices */
- snd_seq_oss_midi_lookup_ports(system_client);
-
/* create annoucement receiver port */
memset(port, 0, sizeof(*port));
strcpy(port->name, "Receiver");
@@ -115,6 +121,9 @@ snd_seq_oss_create_client(void)
}
rc = 0;
+ /* look up midi devices */
+ schedule_work(&async_lookup_work);
+
__error:
kfree(port);
return rc;
@@ -160,6 +169,7 @@ receive_announce(struct snd_seq_event *ev, int direct, void *private, int atomic
int
snd_seq_oss_delete_client(void)
{
+ cancel_work_sync(&async_lookup_work);
if (system_client >= 0)
snd_seq_delete_kernel_client(system_client);
diff --git a/sound/core/seq/oss/seq_oss_midi.c b/sound/core/seq/oss/seq_oss_midi.c
index 677dc84..862d8489 100644
--- a/sound/core/seq/oss/seq_oss_midi.c
+++ b/sound/core/seq/oss/seq_oss_midi.c
@@ -72,7 +72,7 @@ static int send_midi_event(struct seq_oss_devinfo *dp, struct snd_seq_event *ev,
* look up the existing ports
* this looks a very exhausting job.
*/
-int __init
+int
snd_seq_oss_midi_lookup_ports(int client)
{
struct snd_seq_client_info *clinfo;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists