[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0909031731540.24199@V090114053VZO-1>
Date: Thu, 3 Sep 2009 17:44:54 -0500 (CDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: Pekka Enberg <penberg@...helsinki.fi>,
Zdenek Kabelac <zdenek.kabelac@...il.com>,
Patrick McHardy <kaber@...sh.net>, Robin Holt <holt@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jesper Dangaard Brouer <hawk@...x.dk>,
Linux Netdev List <netdev@...r.kernel.org>,
Netfilter Developers <netfilter-devel@...r.kernel.org>,
paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH] slub: fix slab_pad_check()
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists