From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx133.postini.com [74.125.245.133]) by kanga.kvack.org (Postfix) with SMTP id 9FC2C6B005A for ; Tue, 17 Jul 2012 11:11:59 -0400 (EDT) Date: Tue, 17 Jul 2012 10:11:56 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create() In-Reply-To: Message-ID: References: <1342221125.17464.8.camel@lorien2> <1342407840.3190.5.camel@lorien2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: David Rientjes , Shuah Khan , glommer@parallels.com, js1304@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, shuahkhan@gmail.com 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? > As for "in_interrupt()", I really don't see the point in keeping that > around. We could push it down to mm/slab.c in "__kmem_cache_create()" > if we wanted to. Ok we could do that but I guess we are in the discussion of how much checking should be done for a production kernel. I think these checks are way out of hand. We cannot afford to consistently check parameters to all kernel functions in production. We will only do these checks in a select manner if these values could result in serious difficult to debug problems. The checks in slab look like debugging code that someone needed for a specific debugging scenario. I can understand that we would keep that in for development but not for production. Maybe I am a bit biased but my prod kernels need to have minimal memory footprint due to excessive code size causing regressions. -- 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