lkml.org 
[lkml]   [2004]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rmaplock 2/6 SLAB_DESTROY_BY_RCU
Hugh Dickins wrote:

>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.
>
>
>
No, I just tried to reworden your idea and I obviously failed.
Previously, I always assumed that the free call had to be delayed, but
you have shown that this is wrong: If a rcu user can detect that an
object changed its identity (or if he doesn't care), then it's not
necessary to delay the free call, it's sufficient to delay the object
destruction. And since the slab cache is an object cache delaying
destruction causes virtually no overhead at all.
A second restriction is that it must be possible to recover from
identity changes. I think this rules out the dentry cache - the hash
chains point to wrong positions after a free/alloc/reuse cycle, it's not
possible to recover from that.

>>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?
>
>
>
Yes, that should work.

>>- 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.
>
This would introduce a concept of a half destroyed object. I think it's
a bad idea, too easy to introduce bugs.
The correct fix would be to move the whole slab_destroy call into the
rcu callback instead of just the kmem_cache_free call, but locking would
be tricky - kmem_cache_destroy would have to wait for completion of
outstanding rcu calls, etc.
Thus I'd propose a quick fix (fail if there is a dtor - are there any
slab caches with dtors at all?) and in the long run slab_destroy should
be moved into the rcu callback.

--
Manfred
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.054 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site