Messages in this thread Patch in this message | | | Date | Tue, 13 Jul 2004 20:53:29 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] rmaplock 2/6 SLAB_DESTROY_BY_RCU |
| |
On Tue, 13 Jul 2004, Manfred Spraul wrote: > An interesting idea: > The slab caches are object caches. If a rcu user only needs a valid > object but doesn't care which one then there is no need to wait for a > quiescent cycle after free - the quiescent cycle can be delayed until > the destructor is called.
Sorry, to be honest, I've not understood you there at all. I wonder if you're seeing some other use than I intended.
> But there are two flaws in your patch: > - you must disable poisoning and unmapping if SLAB_DESTROY_BY_RCU is set.
How right you are! Thank you. Does the further patch below suit?
> - either delay the dtor calls a well or fail if an object has a non-NULL > dtor and SLAB_DESTROY_BY_RCU is set.
Doesn't that rather depend on what the dtor does? I'm not used to how destructors are commonly used, but I can easily imagine a destructor which, say, frees up some attached objects, but still leaves this cache object recognizably itself, good enough for the reference-after-free which SLAB_DESTROY_BY_RCU is allowing - all we need to avoid is the page being freed (or poisoned or unmapped) and reused. I don't see a need to prohibit or delay dtor necessarily - but there's no question, those who make use of this SLAB_DESTROY_BY_RCU technique do still need to take great care when referencing after free.
Hugh
--- rmaplock6/mm/slab.c 2004-07-12 18:20:35.277828256 +0100 +++ rmaplock7/mm/slab.c 2004-07-13 20:24:27.193884264 +0100 @@ -1196,8 +1196,11 @@ kmem_cache_create (const char *name, siz */ if ((size < 4096 || fls(size-1) == fls(size-1+3*BYTES_PER_WORD))) flags |= SLAB_RED_ZONE|SLAB_STORE_USER; - flags |= SLAB_POISON; + if (!(flags & SLAB_DESTROY_BY_RCU)) + flags |= SLAB_POISON; #endif + if (flags & SLAB_DESTROY_BY_RCU) + BUG_ON(flags & SLAB_POISON); #endif /* * Always checks flags, a caller might be expecting debug - 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/
| |