Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750948AbWHNPeo (ORCPT ); Mon, 14 Aug 2006 11:34:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751120AbWHNPen (ORCPT ); Mon, 14 Aug 2006 11:34:43 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]:63419 "EHLO nf-out-0910.google.com") by vger.kernel.org with ESMTP id S1751014AbWHNPen (ORCPT ); Mon, 14 Aug 2006 11:34:43 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S3NBFy+PzHr62PwUXDGwBwGXqoGI2ygivR5AsNdgZAHsDdLfniEsf4OPz3WCsC2ga64Xs+tsDRjeb0+dbV2XKWK1AcJgwY0+oqm+M1xR+idFpeuYtM8+yDCcqHiBxVCZP4MUvH+WuHI4tpxfQzcVCN56L13WE4YZhHBE2e12a+Y= Message-ID: Date: Mon, 14 Aug 2006 16:34:41 +0100 From: "Catalin Marinas" To: "Michal Piotrowski" Subject: Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9 Cc: linux-kernel@vger.kernel.org In-Reply-To: <6bffcb0e0608130459k1c7e142esbfc2439badf323bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060812215857.17709.79502.stgit@localhost.localdomain> <6bffcb0e0608130459k1c7e142esbfc2439badf323bd@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3807 Lines: 90 On 13/08/06, Michal Piotrowski wrote: > Can you look at this? > ======================================================= > [ INFO: possible circular locking dependency detected ] > ------------------------------------------------------- > events/0/8 is trying to acquire lock: > (old_style_spin_init){++..}, at: [] memleak_free+0x95/0x157 > > but task is already holding lock: > (&parent->list_lock){++..}, at: [] drain_array+0x49/0xad > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (&parent->list_lock){++..}: > [] check_prevs_add+0x4d/0xaf > [] __lock_acquire+0x7b1/0x814 > [] lock_acquire+0x5e/0x7e > [] _spin_lock+0x23/0x2f > [] cache_alloc_refill+0x76/0x1d2 > [] kmem_cache_alloc+0x73/0xce > [] radix_tree_node_alloc+0x1a/0x51 > [] radix_tree_insert+0x51/0xfb > [] insert_alias+0x85/0xe8 > [] memleak_insert_aliases+0x4b/0xa6 > [] memleak_init+0x44/0xf5 > [] start_kernel+0x17e/0x1f9 > [] 0xc0100210 > -> #0 (old_style_spin_init){++..}: > [] check_prevs_add+0x4d/0xaf > [] __lock_acquire+0x7b1/0x814 > [] lock_acquire+0x5e/0x7e > [] _spin_lock+0x23/0x2f > [] memleak_free+0x95/0x157 > [] kmem_cache_free+0x62/0xbc > [] slab_destroy+0x48/0x4d > [] free_block+0xc9/0x101 > [] drain_array+0x85/0xad > [] cache_reap+0x80/0xfe > [] run_workqueue+0x88/0xc4 > [] worker_thread+0xfe/0x131 > [] kthread+0x82/0xaa > [] kernel_thread_helper+0x5/0xb I don't think I fully understand the slab locking, maybe some other kernel guys could help with this, but lockdep is probably right (the lock could happen on SMP systems). It looks like lockdep complains that memleak_lock is acquired while list_lock is held and there is a possibility that (on a different CPU) memleak_lock was acquired first, followed by list_lock acquiring and therefore a deadlock. The kmemleak+slab locking is a bit complicated because memleak itself needs to allocate memory and avoid recursive calls to it (the pointer_cache and the radix_tree allocations). The kmemleak-related allocations are not tracked by kmemleak. I see the following solutions: 1. acquire the memleak_lock at the beginning of an alloc/free function and release it when finished while allowing recursive/nested calls (and only call the memleak_* functions during the outermost lock). This would mean ignoring the off-slab management allocations as these would lead to deadlock because of the recursive call into kmemleak. This locking should be placed around cache_reap() as well (actually, around all the entry points in the mm/slab.c file). 2. do an independent (simple) memory management in kmemleak and probably replace radix_tree with prio_tree as the latter doesn't seem to require allocations. The first option is simple to implement but it has the disadvantage of serializing the slab calls on SMP and also not tracking the mm/slab.c allocations. The second one would provide full coverage of the kernel slab allocations but it is probably more difficult to implement. Any thoughts/suggestions on this? Thanks. -- Catalin - 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/