From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id EAE07B7063 for ; Fri, 14 Aug 2009 17:57:05 +1000 (EST) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 58D50DDD1B for ; Fri, 14 Aug 2009 17:57:04 +1000 (EST) Subject: Re: [PATCH] Add kmemleak annotations to lmb.c From: Benjamin Herrenschmidt To: Catalin Marinas In-Reply-To: <1250178041.14019.34.camel@pc1117.cambridge.arm.com> References: <1250178041.14019.34.camel@pc1117.cambridge.arm.com> Content-Type: text/plain Date: Fri, 14 Aug 2009 17:56:40 +1000 Message-Id: <1250236600.24143.34.camel@pasglop> Mime-Version: 1.0 Cc: linuxppc-dev@ozlabs.org, "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote: > On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote: > > We don't actually want kmemleak to track the lmb allocations, so we > > pass min_count as 0. However telling kmemleak about lmb allocations > > allows it to scan that memory for pointers to other memory that is > > tracked by kmemleak, ie. slab allocations etc. > > Looks alright to me (though I haven't tested it). You can add a > Reviewed-by: Catalin Marinas Actually, Milton pointed to me that we may not want to allow all LMB chunks to be scanned by kmemleaks, things like the DART hole that's taken out of the linear mapping for example may need to be avoided, though I'm not sure what would be the right way to do it. Cheers, Ben.