Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756606Ab0F2PrN (ORCPT ); Tue, 29 Jun 2010 11:47:13 -0400 Received: from nlpi157.sbcis.sbc.com ([207.115.36.171]:55784 "EHLO nlpi157.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756492Ab0F2PrM (ORCPT ); Tue, 29 Jun 2010 11:47:12 -0400 Date: Tue, 29 Jun 2010 10:47:09 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: Benjamin Herrenschmidt cc: linux-mm@kvack.org, "linux-kernel@vger.kernel.org" Subject: Re: kmem_cache_destroy() badness with SLUB In-Reply-To: <1277688701.4200.159.camel@pasglop> Message-ID: References: <1277688701.4200.159.camel@pasglop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 734 Lines: 22 On Mon, 28 Jun 2010, Benjamin Herrenschmidt wrote: > So if the slab is created -and- destroyed at, for example, arch_initcall > time, then we hit a WARN in the kobject code, trying to dispose of a > non-existing kobject. Yes dont do that. > Now, at first sight, just adding the same test to sysfs_slab_remove() > would do the job... but it all seems very racy to me. Yes lets leave as is. Dont remove slabs during boot. > Shouldn't we have a mutex around those guys ? At boot time? -- 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/