I was getting these kmemleak reports when I build SND_SEQUENCER in
kernel :
unreferenced object 0xf6b0ac00 (size 512):
comm "swapper", pid 1, jiffies 4294671240
hex dump (first 32 bytes):
02 00 00 00 03 4f 53 53 20 73 65 71 75 65 6e 63 .....OSS sequenc
65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 er..............
backtrace:
[<c12d7d83>] kmemleak_alloc+0x25/0x49
[<c109350d>] kmem_cache_alloc+0x95/0x124
[<c12568f0>] seq_create_client1+0x1d/0x165
[<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
[<c14c966f>] snd_seq_oss_create_client+0x86/0x143
[<c14c958a>] alsa_seq_oss_init+0xf8/0x157
[<c100104f>] do_one_initcall+0x4a/0x111
[<c14a8608>] kernel_init+0x16b/0x1bc
[<c100352b>] kernel_thread_helper+0x7/0x1a
[<ffffffff>] 0xffffffff
unreferenced object 0xf6b08700 (size 128):
comm "swapper", pid 1, jiffies 4294671240
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<c12d7d83>] kmemleak_alloc+0x25/0x49
[<c109350d>] kmem_cache_alloc+0x95/0x124
[<c12591a3>] snd_seq_pool_new+0x17/0xbe
[<c1256955>] seq_create_client1+0x82/0x165
[<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
[<c14c966f>] snd_seq_oss_create_client+0x86/0x143
[<c14c958a>] alsa_seq_oss_init+0xf8/0x157
[<c100104f>] do_one_initcall+0x4a/0x111
[<c14a8608>] kernel_init+0x16b/0x1bc
[<c100352b>] kernel_thread_helper+0x7/0x1a
[<ffffffff>] 0xffffffff
unreferenced object 0xf6b0aa00 (size 512):
comm "swapper", pid 1, jiffies 4294671246
hex dump (first 32 bytes):
0f 00 00 00 00 00 00 00 52 65 63 65 69 76 65 72 ........Receiver
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<c12d7d83>] kmemleak_alloc+0x25/0x49
[<c109350d>] kmem_cache_alloc+0x95/0x124
[<c125bdf9>] snd_seq_create_port+0x4c/0x197
[<c1257589>] snd_seq_ioctl_create_port+0x52/0x141
[<c1256bb3>] snd_seq_do_ioctl+0x59/0x78
[<c1256c11>] snd_seq_kernel_client_ctl+0x2f/0x48
[<c14c96e1>] snd_seq_oss_create_client+0xf8/0x143
[<c14c958a>] alsa_seq_oss_init+0xf8/0x157
[<c100104f>] do_one_initcall+0x4a/0x111
[<c14a8608>] kernel_init+0x16b/0x1bc
[<c100352b>] kernel_thread_helper+0x7/0x1a
[<ffffffff>] 0xffffffff
But when I build SND_SEQUENCER as module these kmemleak issues
disappear.
Then I noticed that issue was in ordering.
When build in kernel flow is like this :
OSS sequencer(alsa_seq_oss_init) -> System (snd_seq_system_client_init)
When build as modules flow is like this :
System(snd_seq_system_client_init) -> OSS sequencer(alsa_seq_oss_init)
So this fixes above kmemleak issues in my case, I hope it will be
helpful :
diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
index f25e3cc..3ddf2c2 100644
--- a/sound/core/seq/oss/seq_oss.c
+++ b/sound/core/seq/oss/seq_oss.c
@@ -116,7 +116,7 @@ static void __exit alsa_seq_oss_exit(void)
unregister_device();
}
-module_init(alsa_seq_oss_init)
+late_initcall(alsa_seq_oss_init);
module_exit(alsa_seq_oss_exit)
/*
--
JSR
At Sat, 18 Jul 2009 01:44:04 +0530,
Jaswinder Singh Rajput wrote:
>
> I was getting these kmemleak reports when I build SND_SEQUENCER in
> kernel :
>
> unreferenced object 0xf6b0ac00 (size 512):
> comm "swapper", pid 1, jiffies 4294671240
> hex dump (first 32 bytes):
> 02 00 00 00 03 4f 53 53 20 73 65 71 75 65 6e 63 .....OSS sequenc
> 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 er..............
> backtrace:
> [<c12d7d83>] kmemleak_alloc+0x25/0x49
> [<c109350d>] kmem_cache_alloc+0x95/0x124
> [<c12568f0>] seq_create_client1+0x1d/0x165
> [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> [<c100104f>] do_one_initcall+0x4a/0x111
> [<c14a8608>] kernel_init+0x16b/0x1bc
> [<c100352b>] kernel_thread_helper+0x7/0x1a
> [<ffffffff>] 0xffffffff
> unreferenced object 0xf6b08700 (size 128):
> comm "swapper", pid 1, jiffies 4294671240
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<c12d7d83>] kmemleak_alloc+0x25/0x49
> [<c109350d>] kmem_cache_alloc+0x95/0x124
> [<c12591a3>] snd_seq_pool_new+0x17/0xbe
> [<c1256955>] seq_create_client1+0x82/0x165
> [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> [<c100104f>] do_one_initcall+0x4a/0x111
> [<c14a8608>] kernel_init+0x16b/0x1bc
> [<c100352b>] kernel_thread_helper+0x7/0x1a
> [<ffffffff>] 0xffffffff
> unreferenced object 0xf6b0aa00 (size 512):
> comm "swapper", pid 1, jiffies 4294671246
> hex dump (first 32 bytes):
> 0f 00 00 00 00 00 00 00 52 65 63 65 69 76 65 72 ........Receiver
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<c12d7d83>] kmemleak_alloc+0x25/0x49
> [<c109350d>] kmem_cache_alloc+0x95/0x124
> [<c125bdf9>] snd_seq_create_port+0x4c/0x197
> [<c1257589>] snd_seq_ioctl_create_port+0x52/0x141
> [<c1256bb3>] snd_seq_do_ioctl+0x59/0x78
> [<c1256c11>] snd_seq_kernel_client_ctl+0x2f/0x48
> [<c14c96e1>] snd_seq_oss_create_client+0xf8/0x143
> [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> [<c100104f>] do_one_initcall+0x4a/0x111
> [<c14a8608>] kernel_init+0x16b/0x1bc
> [<c100352b>] kernel_thread_helper+0x7/0x1a
> [<ffffffff>] 0xffffffff
>
> But when I build SND_SEQUENCER as module these kmemleak issues
> disappear.
>
> Then I noticed that issue was in ordering.
>
> When build in kernel flow is like this :
>
> OSS sequencer(alsa_seq_oss_init) -> System (snd_seq_system_client_init)
>
> When build as modules flow is like this :
>
> System(snd_seq_system_client_init) -> OSS sequencer(alsa_seq_oss_init)
>
> So this fixes above kmemleak issues in my case, I hope it will be
> helpful :
>
> diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
> index f25e3cc..3ddf2c2 100644
> --- a/sound/core/seq/oss/seq_oss.c
> +++ b/sound/core/seq/oss/seq_oss.c
> @@ -116,7 +116,7 @@ static void __exit alsa_seq_oss_exit(void)
> unregister_device();
> }
>
> -module_init(alsa_seq_oss_init)
> +late_initcall(alsa_seq_oss_init);
> module_exit(alsa_seq_oss_exit)
Thanks for checking this.
Another option would be to fix Makefile. I guess simply putting the
line including sound/core/seq/oss/Makefile after the definitions of
other seq modules would do the same thing...
Takashi
Hello Takashi,
On Sun, 2009-07-19 at 14:07 +0200, Takashi Iwai wrote:
> At Sat, 18 Jul 2009 01:44:04 +0530,
> Jaswinder Singh Rajput wrote:
> >
> > I was getting these kmemleak reports when I build SND_SEQUENCER in
> > kernel :
> >
> > unreferenced object 0xf6b0ac00 (size 512):
> > comm "swapper", pid 1, jiffies 4294671240
> > hex dump (first 32 bytes):
> > 02 00 00 00 03 4f 53 53 20 73 65 71 75 65 6e 63 .....OSS sequenc
> > 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 er..............
> > backtrace:
> > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > [<c12568f0>] seq_create_client1+0x1d/0x165
> > [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> > [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > [<c100104f>] do_one_initcall+0x4a/0x111
> > [<c14a8608>] kernel_init+0x16b/0x1bc
> > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > [<ffffffff>] 0xffffffff
> > unreferenced object 0xf6b08700 (size 128):
> > comm "swapper", pid 1, jiffies 4294671240
> > hex dump (first 32 bytes):
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > [<c12591a3>] snd_seq_pool_new+0x17/0xbe
> > [<c1256955>] seq_create_client1+0x82/0x165
> > [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> > [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > [<c100104f>] do_one_initcall+0x4a/0x111
> > [<c14a8608>] kernel_init+0x16b/0x1bc
> > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > [<ffffffff>] 0xffffffff
> > unreferenced object 0xf6b0aa00 (size 512):
> > comm "swapper", pid 1, jiffies 4294671246
> > hex dump (first 32 bytes):
> > 0f 00 00 00 00 00 00 00 52 65 63 65 69 76 65 72 ........Receiver
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > [<c125bdf9>] snd_seq_create_port+0x4c/0x197
> > [<c1257589>] snd_seq_ioctl_create_port+0x52/0x141
> > [<c1256bb3>] snd_seq_do_ioctl+0x59/0x78
> > [<c1256c11>] snd_seq_kernel_client_ctl+0x2f/0x48
> > [<c14c96e1>] snd_seq_oss_create_client+0xf8/0x143
> > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > [<c100104f>] do_one_initcall+0x4a/0x111
> > [<c14a8608>] kernel_init+0x16b/0x1bc
> > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > [<ffffffff>] 0xffffffff
> >
> > But when I build SND_SEQUENCER as module these kmemleak issues
> > disappear.
> >
> > Then I noticed that issue was in ordering.
> >
> > When build in kernel flow is like this :
> >
> > OSS sequencer(alsa_seq_oss_init) -> System (snd_seq_system_client_init)
> >
> > When build as modules flow is like this :
> >
> > System(snd_seq_system_client_init) -> OSS sequencer(alsa_seq_oss_init)
> >
> > So this fixes above kmemleak issues in my case, I hope it will be
> > helpful :
> >
> > diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
> > index f25e3cc..3ddf2c2 100644
> > --- a/sound/core/seq/oss/seq_oss.c
> > +++ b/sound/core/seq/oss/seq_oss.c
> > @@ -116,7 +116,7 @@ static void __exit alsa_seq_oss_exit(void)
> > unregister_device();
> > }
> >
> > -module_init(alsa_seq_oss_init)
> > +late_initcall(alsa_seq_oss_init);
> > module_exit(alsa_seq_oss_exit)
>
> Thanks for checking this.
>
> Another option would be to fix Makefile. I guess simply putting the
> line including sound/core/seq/oss/Makefile after the definitions of
> other seq modules would do the same thing...
Yes, this also fixes the ordering and memory leak when build
SND_SEQUENCER in kernel and is equivalent to :
1. insmod sound/core/seq/snd-seq-device.ko
2. insmod sound/core/seq/snd-seq.ko
3. insmod sound/core/seq/snd-seq-midi-event.ko
4. insmod sound/core/seq/oss/snd-seq-oss.ko
diff --git a/sound/core/seq/Makefile b/sound/core/seq/Makefile
index 1bcb360..941f64a 100644
--- a/sound/core/seq/Makefile
+++ b/sound/core/seq/Makefile
@@ -3,10 +3,6 @@
# Copyright (c) 1999 by Jaroslav Kysela <[email protected]>
#
-ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
- obj-$(CONFIG_SND_SEQUENCER) += oss/
-endif
-
snd-seq-device-objs := seq_device.o
snd-seq-objs := seq.o seq_lock.o seq_clientmgr.o seq_memory.o seq_queue.o \
seq_fifo.o seq_prioq.o seq_timer.o \
@@ -19,7 +15,8 @@ snd-seq-virmidi-objs := seq_virmidi.o
obj-$(CONFIG_SND_SEQUENCER) += snd-seq.o snd-seq-device.o
ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
-obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
+ obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
+ obj-$(CONFIG_SND_SEQUENCER) += oss/
endif
obj-$(CONFIG_SND_SEQ_DUMMY) += snd-seq-dummy.o
--
JSR
At Sun, 19 Jul 2009 20:56:34 +0530,
Jaswinder Singh Rajput wrote:
>
> Hello Takashi,
>
> On Sun, 2009-07-19 at 14:07 +0200, Takashi Iwai wrote:
> > At Sat, 18 Jul 2009 01:44:04 +0530,
> > Jaswinder Singh Rajput wrote:
> > >
> > > I was getting these kmemleak reports when I build SND_SEQUENCER in
> > > kernel :
> > >
> > > unreferenced object 0xf6b0ac00 (size 512):
> > > comm "swapper", pid 1, jiffies 4294671240
> > > hex dump (first 32 bytes):
> > > 02 00 00 00 03 4f 53 53 20 73 65 71 75 65 6e 63 .....OSS sequenc
> > > 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 er..............
> > > backtrace:
> > > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > > [<c12568f0>] seq_create_client1+0x1d/0x165
> > > [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> > > [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> > > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > > [<c100104f>] do_one_initcall+0x4a/0x111
> > > [<c14a8608>] kernel_init+0x16b/0x1bc
> > > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > > [<ffffffff>] 0xffffffff
> > > unreferenced object 0xf6b08700 (size 128):
> > > comm "swapper", pid 1, jiffies 4294671240
> > > hex dump (first 32 bytes):
> > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > > backtrace:
> > > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > > [<c12591a3>] snd_seq_pool_new+0x17/0xbe
> > > [<c1256955>] seq_create_client1+0x82/0x165
> > > [<c1257b01>] snd_seq_create_kernel_client+0x68/0xe7
> > > [<c14c966f>] snd_seq_oss_create_client+0x86/0x143
> > > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > > [<c100104f>] do_one_initcall+0x4a/0x111
> > > [<c14a8608>] kernel_init+0x16b/0x1bc
> > > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > > [<ffffffff>] 0xffffffff
> > > unreferenced object 0xf6b0aa00 (size 512):
> > > comm "swapper", pid 1, jiffies 4294671246
> > > hex dump (first 32 bytes):
> > > 0f 00 00 00 00 00 00 00 52 65 63 65 69 76 65 72 ........Receiver
> > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > > backtrace:
> > > [<c12d7d83>] kmemleak_alloc+0x25/0x49
> > > [<c109350d>] kmem_cache_alloc+0x95/0x124
> > > [<c125bdf9>] snd_seq_create_port+0x4c/0x197
> > > [<c1257589>] snd_seq_ioctl_create_port+0x52/0x141
> > > [<c1256bb3>] snd_seq_do_ioctl+0x59/0x78
> > > [<c1256c11>] snd_seq_kernel_client_ctl+0x2f/0x48
> > > [<c14c96e1>] snd_seq_oss_create_client+0xf8/0x143
> > > [<c14c958a>] alsa_seq_oss_init+0xf8/0x157
> > > [<c100104f>] do_one_initcall+0x4a/0x111
> > > [<c14a8608>] kernel_init+0x16b/0x1bc
> > > [<c100352b>] kernel_thread_helper+0x7/0x1a
> > > [<ffffffff>] 0xffffffff
> > >
> > > But when I build SND_SEQUENCER as module these kmemleak issues
> > > disappear.
> > >
> > > Then I noticed that issue was in ordering.
> > >
> > > When build in kernel flow is like this :
> > >
> > > OSS sequencer(alsa_seq_oss_init) -> System (snd_seq_system_client_init)
> > >
> > > When build as modules flow is like this :
> > >
> > > System(snd_seq_system_client_init) -> OSS sequencer(alsa_seq_oss_init)
> > >
> > > So this fixes above kmemleak issues in my case, I hope it will be
> > > helpful :
> > >
> > > diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
> > > index f25e3cc..3ddf2c2 100644
> > > --- a/sound/core/seq/oss/seq_oss.c
> > > +++ b/sound/core/seq/oss/seq_oss.c
> > > @@ -116,7 +116,7 @@ static void __exit alsa_seq_oss_exit(void)
> > > unregister_device();
> > > }
> > >
> > > -module_init(alsa_seq_oss_init)
> > > +late_initcall(alsa_seq_oss_init);
> > > module_exit(alsa_seq_oss_exit)
> >
> > Thanks for checking this.
> >
> > Another option would be to fix Makefile. I guess simply putting the
> > line including sound/core/seq/oss/Makefile after the definitions of
> > other seq modules would do the same thing...
>
> Yes, this also fixes the ordering and memory leak when build
> SND_SEQUENCER in kernel and is equivalent to :
>
> 1. insmod sound/core/seq/snd-seq-device.ko
> 2. insmod sound/core/seq/snd-seq.ko
> 3. insmod sound/core/seq/snd-seq-midi-event.ko
> 4. insmod sound/core/seq/oss/snd-seq-oss.ko
>
> diff --git a/sound/core/seq/Makefile b/sound/core/seq/Makefile
> index 1bcb360..941f64a 100644
> --- a/sound/core/seq/Makefile
> +++ b/sound/core/seq/Makefile
> @@ -3,10 +3,6 @@
> # Copyright (c) 1999 by Jaroslav Kysela <[email protected]>
> #
>
> -ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> - obj-$(CONFIG_SND_SEQUENCER) += oss/
> -endif
> -
> snd-seq-device-objs := seq_device.o
> snd-seq-objs := seq.o seq_lock.o seq_clientmgr.o seq_memory.o seq_queue.o \
> seq_fifo.o seq_prioq.o seq_timer.o \
> @@ -19,7 +15,8 @@ snd-seq-virmidi-objs := seq_virmidi.o
>
> obj-$(CONFIG_SND_SEQUENCER) += snd-seq.o snd-seq-device.o
> ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> -obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
> + obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
> + obj-$(CONFIG_SND_SEQUENCER) += oss/
> endif
> obj-$(CONFIG_SND_SEQ_DUMMY) += snd-seq-dummy.o
>
Looks good. Could you give a changelog and your sign-off to merge?
thanks,
Takashi
On Sun, 2009-07-19 at 18:02 +0200, Takashi Iwai wrote:
> Looks good. Could you give a changelog and your sign-off to merge?
>
[PATCH] SOUND: OSS sequencer should be initialized after snd_seq_system_client_init
When build SND_SEQUENCER in kernel then OSS sequencer(alsa_seq_oss_init)
is initialized before System (snd_seq_system_client_init) which leads to
memory leak :
unreferenced object 0xf6b0e680 (size 256):
comm "swapper", pid 1, jiffies 4294670753
backtrace:
[<c108ac5c>] create_object+0x135/0x204
[<c108adfe>] kmemleak_alloc+0x26/0x4c
[<c1087de2>] kmem_cache_alloc+0x72/0xff
[<c126d2ac>] seq_create_client1+0x22/0x160
[<c126e3b6>] snd_seq_create_kernel_client+0x72/0xef
[<c1485a05>] snd_seq_oss_create_client+0x86/0x142
[<c1485920>] alsa_seq_oss_init+0xf6/0x155
[<c1001059>] do_one_initcall+0x4f/0x111
[<c14655be>] kernel_init+0x115/0x166
[<c10032af>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
unreferenced object 0xf688a580 (size 64):
comm "swapper", pid 1, jiffies 4294670753
backtrace:
[<c108ac5c>] create_object+0x135/0x204
[<c108adfe>] kmemleak_alloc+0x26/0x4c
[<c1087de2>] kmem_cache_alloc+0x72/0xff
[<c126f964>] snd_seq_pool_new+0x1c/0xb8
[<c126d311>] seq_create_client1+0x87/0x160
[<c126e3b6>] snd_seq_create_kernel_client+0x72/0xef
[<c1485a05>] snd_seq_oss_create_client+0x86/0x142
[<c1485920>] alsa_seq_oss_init+0xf6/0x155
[<c1001059>] do_one_initcall+0x4f/0x111
[<c14655be>] kernel_init+0x115/0x166
[<c10032af>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
unreferenced object 0xf6b0e480 (size 256):
comm "swapper", pid 1, jiffies 4294670754
backtrace:
[<c108ac5c>] create_object+0x135/0x204
[<c108adfe>] kmemleak_alloc+0x26/0x4c
[<c1087de2>] kmem_cache_alloc+0x72/0xff
[<c12725a0>] snd_seq_create_port+0x51/0x21c
[<c126de50>] snd_seq_ioctl_create_port+0x57/0x13c
[<c126d07a>] snd_seq_do_ioctl+0x4a/0x69
[<c126d0de>] snd_seq_kernel_client_ctl+0x33/0x49
[<c1485a74>] snd_seq_oss_create_client+0xf5/0x142
[<c1485920>] alsa_seq_oss_init+0xf6/0x155
[<c1001059>] do_one_initcall+0x4f/0x111
[<c14655be>] kernel_init+0x115/0x166
[<c10032af>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
The correct order should be :
System (snd_seq_system_client_init) should be initialized before
OSS sequencer(alsa_seq_oss_init) which is equivalent to :
1. insmod sound/core/seq/snd-seq-device.ko
2. insmod sound/core/seq/snd-seq.ko
3. insmod sound/core/seq/snd-seq-midi-event.ko
4. insmod sound/core/seq/oss/snd-seq-oss.ko
Including sound/core/seq/oss/Makefile after other seq modules
fixes the ordering and memory leak.
Signed-off-by: Jaswinder Singh Rajput <[email protected]>
---
sound/core/seq/Makefile | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/sound/core/seq/Makefile b/sound/core/seq/Makefile
index 1bcb360..941f64a 100644
--- a/sound/core/seq/Makefile
+++ b/sound/core/seq/Makefile
@@ -3,10 +3,6 @@
# Copyright (c) 1999 by Jaroslav Kysela <[email protected]>
#
-ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
- obj-$(CONFIG_SND_SEQUENCER) += oss/
-endif
-
snd-seq-device-objs := seq_device.o
snd-seq-objs := seq.o seq_lock.o seq_clientmgr.o seq_memory.o seq_queue.o \
seq_fifo.o seq_prioq.o seq_timer.o \
@@ -19,7 +15,8 @@ snd-seq-virmidi-objs := seq_virmidi.o
obj-$(CONFIG_SND_SEQUENCER) += snd-seq.o snd-seq-device.o
ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
-obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
+ obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
+ obj-$(CONFIG_SND_SEQUENCER) += oss/
endif
obj-$(CONFIG_SND_SEQ_DUMMY) += snd-seq-dummy.o
--
1.6.0.6
At Sun, 19 Jul 2009 21:58:34 +0530,
Jaswinder Singh Rajput wrote:
>
> On Sun, 2009-07-19 at 18:02 +0200, Takashi Iwai wrote:
>
> > Looks good. Could you give a changelog and your sign-off to merge?
> >
>
> [PATCH] SOUND: OSS sequencer should be initialized after snd_seq_system_client_init
>
> When build SND_SEQUENCER in kernel then OSS sequencer(alsa_seq_oss_init)
> is initialized before System (snd_seq_system_client_init) which leads to
> memory leak :
>
> unreferenced object 0xf6b0e680 (size 256):
> comm "swapper", pid 1, jiffies 4294670753
> backtrace:
> [<c108ac5c>] create_object+0x135/0x204
> [<c108adfe>] kmemleak_alloc+0x26/0x4c
> [<c1087de2>] kmem_cache_alloc+0x72/0xff
> [<c126d2ac>] seq_create_client1+0x22/0x160
> [<c126e3b6>] snd_seq_create_kernel_client+0x72/0xef
> [<c1485a05>] snd_seq_oss_create_client+0x86/0x142
> [<c1485920>] alsa_seq_oss_init+0xf6/0x155
> [<c1001059>] do_one_initcall+0x4f/0x111
> [<c14655be>] kernel_init+0x115/0x166
> [<c10032af>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> unreferenced object 0xf688a580 (size 64):
> comm "swapper", pid 1, jiffies 4294670753
> backtrace:
> [<c108ac5c>] create_object+0x135/0x204
> [<c108adfe>] kmemleak_alloc+0x26/0x4c
> [<c1087de2>] kmem_cache_alloc+0x72/0xff
> [<c126f964>] snd_seq_pool_new+0x1c/0xb8
> [<c126d311>] seq_create_client1+0x87/0x160
> [<c126e3b6>] snd_seq_create_kernel_client+0x72/0xef
> [<c1485a05>] snd_seq_oss_create_client+0x86/0x142
> [<c1485920>] alsa_seq_oss_init+0xf6/0x155
> [<c1001059>] do_one_initcall+0x4f/0x111
> [<c14655be>] kernel_init+0x115/0x166
> [<c10032af>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> unreferenced object 0xf6b0e480 (size 256):
> comm "swapper", pid 1, jiffies 4294670754
> backtrace:
> [<c108ac5c>] create_object+0x135/0x204
> [<c108adfe>] kmemleak_alloc+0x26/0x4c
> [<c1087de2>] kmem_cache_alloc+0x72/0xff
> [<c12725a0>] snd_seq_create_port+0x51/0x21c
> [<c126de50>] snd_seq_ioctl_create_port+0x57/0x13c
> [<c126d07a>] snd_seq_do_ioctl+0x4a/0x69
> [<c126d0de>] snd_seq_kernel_client_ctl+0x33/0x49
> [<c1485a74>] snd_seq_oss_create_client+0xf5/0x142
> [<c1485920>] alsa_seq_oss_init+0xf6/0x155
> [<c1001059>] do_one_initcall+0x4f/0x111
> [<c14655be>] kernel_init+0x115/0x166
> [<c10032af>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
> The correct order should be :
>
> System (snd_seq_system_client_init) should be initialized before
> OSS sequencer(alsa_seq_oss_init) which is equivalent to :
>
> 1. insmod sound/core/seq/snd-seq-device.ko
> 2. insmod sound/core/seq/snd-seq.ko
> 3. insmod sound/core/seq/snd-seq-midi-event.ko
> 4. insmod sound/core/seq/oss/snd-seq-oss.ko
>
> Including sound/core/seq/oss/Makefile after other seq modules
> fixes the ordering and memory leak.
>
> Signed-off-by: Jaswinder Singh Rajput <[email protected]>
Thanks, applied now.
Takashi
> ---
> sound/core/seq/Makefile | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/sound/core/seq/Makefile b/sound/core/seq/Makefile
> index 1bcb360..941f64a 100644
> --- a/sound/core/seq/Makefile
> +++ b/sound/core/seq/Makefile
> @@ -3,10 +3,6 @@
> # Copyright (c) 1999 by Jaroslav Kysela <[email protected]>
> #
>
> -ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> - obj-$(CONFIG_SND_SEQUENCER) += oss/
> -endif
> -
> snd-seq-device-objs := seq_device.o
> snd-seq-objs := seq.o seq_lock.o seq_clientmgr.o seq_memory.o seq_queue.o \
> seq_fifo.o seq_prioq.o seq_timer.o \
> @@ -19,7 +15,8 @@ snd-seq-virmidi-objs := seq_virmidi.o
>
> obj-$(CONFIG_SND_SEQUENCER) += snd-seq.o snd-seq-device.o
> ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> -obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
> + obj-$(CONFIG_SND_SEQUENCER) += snd-seq-midi-event.o
> + obj-$(CONFIG_SND_SEQUENCER) += oss/
> endif
> obj-$(CONFIG_SND_SEQ_DUMMY) += snd-seq-dummy.o
>
> --
> 1.6.0.6
>
>
>
On Sun, 2009-07-19 at 21:58 +0530, Jaswinder Singh Rajput wrote:
> [PATCH] SOUND: OSS sequencer should be initialized after snd_seq_system_client_init
>
> When build SND_SEQUENCER in kernel then OSS sequencer(alsa_seq_oss_init)
> is initialized before System (snd_seq_system_client_init) which leads to
> memory leak :
Thanks for investigating this. I haven't looked at the code in detail
but I find it a bit weird that initialisation order fixes the memory
leak. Shouldn't the memory allocation logic change slightly to avoid the
leak as well (that's in case someone manually inserts the modules in the
wrong order)?
--
Catalin
Hello Catalin,
On Sun, 2009-07-19 at 23:19 +0100, Catalin Marinas wrote:
> On Sun, 2009-07-19 at 21:58 +0530, Jaswinder Singh Rajput wrote:
> > [PATCH] SOUND: OSS sequencer should be initialized after snd_seq_system_client_init
> >
> > When build SND_SEQUENCER in kernel then OSS sequencer(alsa_seq_oss_init)
> > is initialized before System (snd_seq_system_client_init) which leads to
> > memory leak :
>
> Thanks for investigating this. I haven't looked at the code in detail
> but I find it a bit weird that initialisation order fixes the memory
> leak. Shouldn't the memory allocation logic change slightly to avoid the
> leak as well (that's in case someone manually inserts the modules in the
> wrong order)?
>
No, you cannot change the order of modules because
'insmod sound/core/seq/oss/snd-seq-oss.ko' need following symbols :
[ 385.258252] snd_seq_oss: Unknown symbol snd_seq_kernel_client_enqueue
[ 385.258435] snd_seq_oss: Unknown symbol snd_seq_set_queue_tempo
[ 385.258639] snd_seq_oss: Unknown symbol snd_seq_delete_kernel_client
[ 385.258751] snd_seq_oss: Unknown symbol snd_seq_autoload_lock
[ 385.258871] snd_seq_oss: Unknown symbol snd_seq_kernel_client_dispatch
[ 385.259782] snd_seq_oss: Unknown symbol snd_seq_kernel_client_enqueue_blocking
[ 385.260191] snd_seq_oss: Unknown symbol snd_seq_autoload_unlock
[ 385.260418] snd_seq_oss: Unknown symbol snd_seq_device_register_driver
[ 385.260537] snd_seq_oss: Unknown symbol snd_midi_event_free
[ 385.260701] snd_seq_oss: Unknown symbol snd_midi_event_no_status
[ 385.260964] snd_seq_oss: Unknown symbol snd_use_lock_sync_helper
[ 385.261469] snd_seq_oss: Unknown symbol snd_seq_device_unregister_driver
[ 385.261659] snd_seq_oss: Unknown symbol snd_seq_event_port_detach
[ 385.261768] snd_seq_oss: Unknown symbol snd_midi_event_new
[ 385.261910] snd_seq_oss: Unknown symbol snd_midi_event_decode
[ 385.262067] snd_seq_oss: Unknown symbol snd_seq_create_kernel_client
[ 385.262233] snd_seq_oss: Unknown symbol snd_seq_kernel_client_write_poll
[ 385.262432] snd_seq_oss: Unknown symbol snd_midi_event_encode_byte
[ 385.262963] snd_seq_oss: Unknown symbol snd_seq_kernel_client_ctl
And we can get these symbols in this way :
1. insmod sound/core/seq/snd-seq-device.ko
[ 385.258751] snd_seq_oss: Unknown symbol snd_seq_autoload_lock
[ 385.260191] snd_seq_oss: Unknown symbol snd_seq_autoload_unlock
[ 385.260418] snd_seq_oss: Unknown symbol snd_seq_device_register_driver
[ 385.261469] snd_seq_oss: Unknown symbol snd_seq_device_unregister_driver
2. insmod sound/core/seq/snd-seq.ko
[ 385.258252] snd_seq_oss: Unknown symbol snd_seq_kernel_client_enqueue
[ 385.258435] snd_seq_oss: Unknown symbol snd_seq_set_queue_tempo
[ 385.258639] snd_seq_oss: Unknown symbol snd_seq_delete_kernel_client
[ 385.258871] snd_seq_oss: Unknown symbol snd_seq_kernel_client_dispatch
[ 385.259782] snd_seq_oss: Unknown symbol snd_seq_kernel_client_enqueue_blocking
[ 385.260964] snd_seq_oss: Unknown symbol snd_use_lock_sync_helper
[ 385.261659] snd_seq_oss: Unknown symbol snd_seq_event_port_detach
[ 385.262067] snd_seq_oss: Unknown symbol snd_seq_create_kernel_client
[ 385.262233] snd_seq_oss: Unknown symbol snd_seq_kernel_client_write_poll
[ 385.262963] snd_seq_oss: Unknown symbol snd_seq_kernel_client_ctl
3. insmod sound/core/seq/snd-seq-midi-event.ko
[ 385.260701] snd_seq_oss: Unknown symbol snd_midi_event_no_status
[ 385.260537] snd_seq_oss: Unknown symbol snd_midi_event_free
[ 385.261768] snd_seq_oss: Unknown symbol snd_midi_event_new
[ 385.261910] snd_seq_oss: Unknown symbol snd_midi_event_decode
[ 385.262432] snd_seq_oss: Unknown symbol snd_midi_event_encode_byte
So the only order is :
1. insmod sound/core/seq/snd-seq-device.ko
2. insmod sound/core/seq/snd-seq.ko
3. insmod sound/core/seq/snd-seq-midi-event.ko
4. insmod sound/core/seq/oss/snd-seq-oss.ko
which is correct, if you change the order like we was getting in
build-in kernel, which leads to improper initialization and memory leak
was the side-effect.
Thanks,
--
JSR