Messages in this thread | | | Date | Tue, 30 Jun 2009 09:58:22 +0300 | Subject | Re: [PATCH RFC] fix RCU-callback-after-kmem_cache_destroy problem in sl[aou]b | From | Pekka Enberg <> |
| |
On Tue, Jun 30, 2009 at 9:00 AM, Paul E. McKenney<paulmck@linux.vnet.ibm.com> wrote: > On Mon, Jun 29, 2009 at 07:06:34PM -0500, Matt Mackall wrote: >> On Mon, 2009-06-29 at 19:19 -0400, Christoph Lameter wrote: >> > On Mon, 29 Jun 2009, Matt Mackall wrote: >> > >> > > This is a reasonable point, and in keeping with the design principle >> > > 'callers should handle their own special cases'. However, I think it >> > > would be more than a little surprising for kmem_cache_free() to do the >> > > right thing, but not kmem_cache_destroy(). >> > >> > kmem_cache_free() must be used carefully when using SLAB_DESTROY_BY_RCU. >> > The freed object can be accessed after free until the rcu interval >> > expires (well sortof, it may even be reallocated within the interval). >> > >> > There are special RCU considerations coming already with the use of >> > kmem_cache_free(). >> > >> > Adding RCU operations to the kmem_cache_destroy() logic may result in >> > unnecessary RCU actions for slabs where the coder is ensuring that the >> > RCU interval has passed by other means. >> >> Do we care? Cache destruction shouldn't be in anyone's fast path. >> Correctness is more important and users are more liable to be correct >> with this patch. > > I am with Matt on this one -- if we are going to hand the users of > SLAB_DESTROY_BY_RCU a hand grenade, let's at least leave the pin in.
I don't even claim to understand all the RCU details here but I don't see why we should care about _kmem_cache_destroy()_ performance at this level. Christoph, hmmm?
Pekka
| |