Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756536AbZICWVB (ORCPT ); Thu, 3 Sep 2009 18:21:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756526AbZICWVA (ORCPT ); Thu, 3 Sep 2009 18:21:00 -0400 Received: from gw1.cosmosbay.com ([212.99.114.194]:36592 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756524AbZICWU5 (ORCPT ); Thu, 3 Sep 2009 18:20:57 -0400 Message-ID: <4AA0407E.8030505@gmail.com> Date: Fri, 04 Sep 2009 00:17:34 +0200 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christoph Lameter CC: "Paul E. McKenney" , Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers Subject: Re: [PATCH] slub: fix slab_pad_check() References: <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> <4A9FCDC6.3060003@gmail.com> <4A9FDA72.8060001@gmail.com> <20090903174435.GF6761@linux.vnet.ibm.com> <4AA03E6A.7070800@gmail.com> In-Reply-To: <4AA03E6A.7070800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Fri, 04 Sep 2009 00:17:35 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2340 Lines: 62 Eric Dumazet a ?crit : > > > > Problem is not _objects_ Christoph, but _slabs_, and your patch is not working. > > Its true that when User calls kmem_cache_destroy(), all _objects_ were previously freed. > This is mandatory, with or withou SLAB_DESTROY_BY_RCU thing > > Problem is that slub has some internal state, including some to-be-freed _slabs_, > that User have no control at all on it. > > User cannot "know" slabs are freed, inuse, or whatever state in cache or call_rcu queues. > > Face it, SLAB_DESTROY_BY_RCU is internal affair (to slub/slab/... allocators) > > We absolutely need a rcu_barrier() somewhere, believe it or not. You can argue that it should > be done *before*, but it gives no speedup, only potential bugs. > > Only case User should do its rcu_barrier() itself is if it knows some call_rcu() are pending > and are delaying _objects_ freeing (typical !SLAB_DESTROY_RCU usage in RCU algos). > > I dont even understand why you care so much about kmem_cache_destroy(SLAB_DESTROY_BY_RCU), > given that almost nobody use it. We took almost one month to find out what the bug was in first > place... So maybe the safest thing would be to include the rcu_barrier() to insure all objects where freed And another one for SLAB_DESTROY_BY_RCU to make sure slabs where freed void kmem_cache_destroy(struct kmem_cache *s) { /* * Make sure no objects are waiting in call_rcu queues to be freed */ rcu_barrier(); down_write(&slub_lock); s->refcount--; if (!s->refcount) { list_del(&s->list); up_write(&slub_lock); if (kmem_cache_close(s)) { printk(KERN_ERR "SLUB %s: %s called for cache that " "still has objects.\n", s->name, __func__); dump_stack(); } /* * Make sure no slabs are waiting in call_rcu queues to be freed */ if (s->flags & SLAB_DESTROY_BY_RCU) rcu_barrier(); sysfs_slab_remove(s); } else up_write(&slub_lock); } -- 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/