[RFC] Making talloc_reference() safer.
rusty at rustcorp.com.au
Mon Oct 24 00:11:42 MDT 2011
I had the fun of re-arguing talloc_reference() safety with
Tridge last Thursday. We agree that talloc_reference fills a real need,
but we can make it safer by expanding the checks which differentiate
normal from refcounted objects.
Firstly, note that talloc_reference() has several real use cases:
anywhere that reference counts would normally be used. The patterns
I've seen are:
1) A "cache" of objects, where the cache may evict objects. The cache
wants to hold a reference, as do the callers, and the object is freed
if it's evicted from the cache *and* noone else has referenced it.
2) A "dealer" of single objects, such as the tdb_wrap code which will
keeps track of all tdbs and avoids reopening the same tdb by handing
back a referenced tdb.
In both cases, talloc_reference() is appropriate, but like any explicit
reference counting, it's a bug to simply free the object. The usability
problem is that talloc_reference() greatly hides this bug (though less
than it used to, now talloc_steal and talloc_free are mainly banned).
Thus, the following patches:
1) Add talloc_may_reference(). This is used to mark an object that may
be referenced in future (such as a cache or dealer handing it out the
first time). Turns on all the runtime checks (no talloc_steal, or
talloc_free) even if it doesn't *currently* have a reference. Also
add a warning for talloc_parent() and talloc_parent_name().
2) Then, a global flag to warn if you don'tset talloc_may_reference()
before you take a reference. This means you can't just
talloc_reference() on any object. Since this is an API change, the
flag defaults to off.
(Note that the flag infrastructure can be enhanced later to add runtime
control of things currently ifdefed:
- talloc_steal-to-self warning
- talloc_report printing contents)
More information about the samba-technical