Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933865AbZIDS4r (ORCPT ); Fri, 4 Sep 2009 14:56:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933827AbZIDS4q (ORCPT ); Fri, 4 Sep 2009 14:56:46 -0400 Received: from smtp2.ultrahosting.com ([74.213.174.253]:37349 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933788AbZIDS4o (ORCPT ); Fri, 4 Sep 2009 14:56:44 -0400 Date: Fri, 4 Sep 2009 11:33:26 -0400 (EDT) From: Christoph Lameter X-X-Sender: cl@V090114053VZO-1 To: "Paul E. McKenney" cc: Eric Dumazet , 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() In-Reply-To: <20090903220300.GN6761@linux.vnet.ibm.com> Message-ID: References: <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> <20090903220300.GN6761@linux.vnet.ibm.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) 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: 1371 Lines: 34 On Thu, 3 Sep 2009, Paul E. McKenney wrote: > > You need to ensure that no objects are in use before destroying a slab. In > > case of DESTROY_BY_RCU you must ensure that there are no potential > > readers. So use a suitable rcu barrier or something else like a > > synchronize_rcu... > > If by "you must ensure" you mean "kmem_cache_destroy must ensure", then > we are in complete agreement. Otherwise, not a chance. Well then we are going down to a crappy interface and mixing rcu with slab semantics. More bugs to follow in the future. > If by "must ensure that no objects are in use", you mean "must have > no further references to them", then we are in agreement. And in my > scenario above, it is not the -user- who later references the memory, > but rather the slab code itself. The slab code itself is not referencing the later memory with my patch. It can only be the user. > Put the rcu_barrier() in kmem_cache_free(). Please. Guess we are doing this ... Sigh. Are you going to add support other rcu versions to slab as well as time permits and as the need arises? Should we add you as a maintainer? ;-) -- 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/