Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932527AbZICXO5 (ORCPT ); Thu, 3 Sep 2009 19:14:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932516AbZICXO4 (ORCPT ); Thu, 3 Sep 2009 19:14:56 -0400 Received: from smtp2.ultrahosting.com ([74.213.174.253]:33889 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932513AbZICXOz (ORCPT ); Thu, 3 Sep 2009 19:14:55 -0400 Date: Thu, 3 Sep 2009 17:44:54 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@V090114053VZO-1 To: Eric Dumazet cc: Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers , paulmck@linux.vnet.ibm.com Subject: Re: [PATCH] slub: fix slab_pad_check() In-Reply-To: <4AA00400.1030005@gmail.com> Message-ID: References: <4A87CE60.4020506@gmail.com> <4A896324.3040104@trash.net> <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> <4A9FCDC6.3060003@gmail.com> <4A9FDA72.8060001@gmail.com> <4AA00400.1030005@gmail.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: 1200 Lines: 26 On Thu, 3 Sep 2009, Eric Dumazet wrote: > It seems very smart, but needs review of all callers to make sure no slabs > are waiting for final freeing in call_rcu queue on some cpu. Yes. Again this is the first time we encounter a situation where a DESTROY_BY_RCU slab has to be destroyed. So the review is quite short. > I suspect most of them will then have to use rcu_barrier() before calling > kmem_cache_destroy(), so why not factorizing code in one place ? There are different forms of RCU which require different forms of barriers. Its best to leave that up to the user. Again the user must make sure that no objects are in use before a slab is destroyed. For SLAB_DESTROY_BY_RCU this means that there are no potential outstanding reads on the structure. You may need an rcu_barrier() to accomplish that. Slight variations in the use of RCU could require different method. Better reduce the entanglement of slabs to RCU to a mininum possible. -- 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/