From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758172AbXFAX5o (ORCPT ); Fri, 1 Jun 2007 19:57:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757228AbXFAX5i (ORCPT ); Fri, 1 Jun 2007 19:57:38 -0400 Received: from smtp1.linux-foundation.org ([207.189.120.13]:56610 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757171AbXFAX5h (ORCPT ); Fri, 1 Jun 2007 19:57:37 -0400 Date: Fri, 1 Jun 2007 16:57:20 -0700 (PDT) From: Linus Torvalds To: Christoph Lameter cc: Andrew Morton , Jeremy Fitzhardinge , Srinivasa Ds , linux-kernel@vger.kernel.org, Srivatsa Vaddagiri , Dinakar Guniguntala , pj@sgi.com, simon.derr@bull.net, clameter@cthulhu.engr.sgi.com, rientjes@google.com Subject: Re: [RFC] [PATCH] cpuset operations causes Badness at mm/slab.c:777 warning In-Reply-To: Message-ID: References: <465FCA79.70207@in.ibm.com> <200706011620.05756.srinivasa@in.ibm.com> <466081DE.70205@goop.org> <20070601135900.ec44b1aa.akpm@linux-foundation.org> <20070601151649.bb23c6f9.akpm@linux-foundation.org> <20070601153328.1118ccaf.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 1 Jun 2007, Christoph Lameter wrote: > > A too large alloc is >32MB or MAX_ORDER << PAGE_SIZE. A BUG_ON in > kmalloc_slab() will trigger. Did we use to BUG_ON()? I think that's wrong. There are ways for users to potentially ask the kernel to do big allocations, and the correct response is to say "no can do", not to crash! > Here is the updated patch. It works fine here: > > SLUB: Return BADPTR instead of warning for kmalloc(0) Looks fine to me. My only comment is that > - if (!x) > + if (!x || x == BADPTR) > return; This could be micro-optimized (again, non-standard, but it should be "practically portable") to have just a single test using something like if ((unsigned long)x <= 16) return; but I guess it doesn't really matter much. I think this is better than what we have now, but I also suspect it's *not* something we should try this late in the -rc sequence ;) Andrew, want to take this patch to -mm to see if it triggers anything? Linus