From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx197.postini.com [74.125.245.197]) by kanga.kvack.org (Postfix) with SMTP id CBF576B005A for ; Mon, 23 Jul 2012 03:07:21 -0400 (EDT) Message-ID: <500CF782.4060407@parallels.com> Date: Mon, 23 Jul 2012 11:04:34 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create() References: <1342221125.17464.8.camel@lorien2> <1342407840.3190.5.camel@lorien2> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Pekka Enberg , David Rientjes , Shuah Khan , js1304@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, shuahkhan@gmail.com On 07/17/2012 07:11 PM, Christoph Lameter wrote: > On Tue, 17 Jul 2012, Pekka Enberg wrote: > >> Well, even SLUB checks for !name in mainline so that's definitely >> worth including unconditionally. Furthermore, the size related checks >> certainly make sense and I don't see any harm in having them as well. > > There is a WARN_ON() there and then it returns NULL!!! Crazy. Causes a > NULL pointer dereference later in the caller? > It obviously depends on the caller. Although most of the calls to kmem_cache_create are made from static data, we can't assume that. Of course whoever is using static data should do those very same tests from the outside to be safe, but in case they do not, this seems to fall in the category of things that make debugging easier - even if we later on get to a NULL pointer dereference. Your mentioned bias towards minimum code size, however, is totally valid, IMHO. But I doubt those checks would introduce a huge footprint. I would imagine you being much more concerned about being able to wipe out entire subsystems like memcg, which will give you a lot more. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org