Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751325AbWHOPZk (ORCPT ); Tue, 15 Aug 2006 11:25:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752103AbWHOPZj (ORCPT ); Tue, 15 Aug 2006 11:25:39 -0400 Received: from nz-out-0102.google.com ([64.233.162.193]:2728 "EHLO nz-out-0102.google.com") by vger.kernel.org with ESMTP id S1751243AbWHOPZj (ORCPT ); Tue, 15 Aug 2006 11:25:39 -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=kKDH7D4euXiSjqOEJUv2eTtDkv4g21c1RMKH4EMWwWY1Cq/wd57qO5K0xx3Cc1Ukgafvr9gmK+DPmYbbaxFr+G3FOBxwTGfrPgyTr146BkNMovQv/6rH/A1KEkNrBElJnCDNavOkqiVfE2VKABmZXCN8wPWNbMRnHKK/M6FvFEo= Message-ID: Date: Tue, 15 Aug 2006 16:25:38 +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: 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: 1407 Lines: 30 On 14/08/06, Catalin Marinas wrote: > 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). This would actually work because the slab allocation functions may sleep. The simple solution would be to eliminate the memory allocations when memleak_lock is held, maybe by replacing the radix tree with a prio search tree (not sure what the performance impact will be). I'll try to go this route and see how it works. -- 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/