Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754392AbZLBGbj (ORCPT ); Wed, 2 Dec 2009 01:31:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751728AbZLBGbi (ORCPT ); Wed, 2 Dec 2009 01:31:38 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:51316 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbZLBGbi (ORCPT ); Wed, 2 Dec 2009 01:31:38 -0500 Message-ID: <4B1609D0.6030809@cs.helsinki.fi> Date: Wed, 02 Dec 2009 08:31:44 +0200 From: Pekka Enberg User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Catalin Marinas CC: hooanon05@yahoo.co.jp, linux-kernel@vger.kernel.org Subject: Re: Q, slab, kmemleak_erase() and redzone? References: <4B1502E3.4000304@cs.helsinki.fi> <1259690210.2121.233.camel@pc1117.cambridge.arm.com> In-Reply-To: <1259690210.2121.233.camel@pc1117.cambridge.arm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1514 Lines: 32 Catalin Marinas kirjoitti: > On Tue, 2009-12-01 at 11:49 +0000, Pekka Enberg wrote: >> hooanon05@yahoo.co.jp kirjoitti: >>> Pekka Enberg: >>>> We are setting an element in the per CPU array to NULL so the the >>>> kmemleak code in ____cache_alloc() is safe. Red-zoning is done at the >>>> _object_ which is not touched by kmemleak. Looking at the oops, it >>>> does seem likely that you have a bug in your module (or in some other >>>> part of the kernel). >>> Thanks for reply. >>> In ____cache_alloc(), the variable 'ac' is assigned before >>> cache_alloc_refill() call, and it is used for the parameter of >>> kmemleak_erase(). The value may be changed by cache_alloc_refill(), >>> isn't it? >> No. The pointer returned by cpu_cache_get() is not changed by >> cache_alloc_refill(). The contents of the array might change, yes. That >> said, we should check if objp is NULL before calling kmemleak_erase(). > > Possibly but I don't understand why that's needed. The kmemleak_erase() > call just sets the ac->entry[ac->avail] to NULL. If ac->avail is 0, it > doesn't cause any harm. No, you are absolutely correct. Can you please send an updated patch to Catalin that adds a comment on top of the cpu_cache_get() call that explains why we need it there? Pekka -- 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/