Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754699AbZGSP10 (ORCPT ); Sun, 19 Jul 2009 11:27:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754677AbZGSP1Y (ORCPT ); Sun, 19 Jul 2009 11:27:24 -0400 Received: from hera.kernel.org ([140.211.167.34]:59434 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754566AbZGSP1W (ORCPT ); Sun, 19 Jul 2009 11:27:22 -0400 Subject: Re: kmemleak issues in alsa From: Jaswinder Singh Rajput To: Takashi Iwai Cc: Mark Brown , Catalin Marinas , LKML , Sam Ravnborg In-Reply-To: References: <1247861644.4513.15.camel@ht.satnam> Content-Type: text/plain Date: Sun, 19 Jul 2009 20:56:34 +0530 Message-Id: <1248017194.2548.3.camel@ht.satnam> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5241 Lines: 136 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: > > [] kmemleak_alloc+0x25/0x49 > > [] kmem_cache_alloc+0x95/0x124 > > [] seq_create_client1+0x1d/0x165 > > [] snd_seq_create_kernel_client+0x68/0xe7 > > [] snd_seq_oss_create_client+0x86/0x143 > > [] alsa_seq_oss_init+0xf8/0x157 > > [] do_one_initcall+0x4a/0x111 > > [] kernel_init+0x16b/0x1bc > > [] kernel_thread_helper+0x7/0x1a > > [] 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: > > [] kmemleak_alloc+0x25/0x49 > > [] kmem_cache_alloc+0x95/0x124 > > [] snd_seq_pool_new+0x17/0xbe > > [] seq_create_client1+0x82/0x165 > > [] snd_seq_create_kernel_client+0x68/0xe7 > > [] snd_seq_oss_create_client+0x86/0x143 > > [] alsa_seq_oss_init+0xf8/0x157 > > [] do_one_initcall+0x4a/0x111 > > [] kernel_init+0x16b/0x1bc > > [] kernel_thread_helper+0x7/0x1a > > [] 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: > > [] kmemleak_alloc+0x25/0x49 > > [] kmem_cache_alloc+0x95/0x124 > > [] snd_seq_create_port+0x4c/0x197 > > [] snd_seq_ioctl_create_port+0x52/0x141 > > [] snd_seq_do_ioctl+0x59/0x78 > > [] snd_seq_kernel_client_ctl+0x2f/0x48 > > [] snd_seq_oss_create_client+0xf8/0x143 > > [] alsa_seq_oss_init+0xf8/0x157 > > [] do_one_initcall+0x4a/0x111 > > [] kernel_init+0x16b/0x1bc > > [] kernel_thread_helper+0x7/0x1a > > [] 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 # -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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/