hmm.. Re: talloc issues

[Derrell Lipman]

On Tue, Aug 4, 2009 at 12:03, Sam Liddicott <sam at liddicott.com> wrote:

> > This should be perfectly analogous to a file system. Someone creates a
> > file which allocates a unique inode. Someone else needs to ensure that
> > the inode sticks around until they're finished using it so they create a
> > hard link to that file. They have created a second reference to the same
> > inode, thus increasing that inode's reference (link) count. Each
> > reference to that file, the original name or the new name, points to the
> > same inode. Either one can be freed (unlinked) at any time without
> > concern for any other user of the inode and with no need to know that
> > there are other references to the same inode. Each free (unlink)
> > decrements the reference count of the inode. When the final reference is
> > freed (unlinked), the inode's reference count goes to zero and the inode
> > can be deallocated.
> >
> > talloc() = creat()
> > talloc_free() = unlink()
> > talloc_reference() = link()
> > talloc_unreference() = unlink()
> >
> > and furthermore,
> >
> > talloc_steal() = rename()
> >
> > The allocated memory itself (the inode) has no concept of parent;
>
> this is not necessarily true with talloc. It doesn't HAVE to have an
> idea of parent - you can make the parent NULL and all references owned
> by NULL, and then you can just call talloc_unlink(NULL, pointer) - to
> use your example.
>

But NULL *is* a parent. It's just effectively mapped, internally, to the
"root". Creating a reference to a NULL context simply creates a reference
that's a top-level node attached to the root of the tree. There's nothing
special there at all.

>
> But talloc is er... bigger; and there can be a parent - which is really
> the main advantage because it means that most of the time you don't need
> to worry about how to free something.


I see:
1. Every allocated object (inode) has at least one reference
2. When the last reference goes away:
  2.1. if the object's reference count is greater than 1, the reference
count is simply decremented
  2.2. if the reference count was already 1, all of the object's children
are deallocated, recursively, and the object itself is deallocated
      2.2.1 If, however, the recursive descent reaches a node that has a
reference count greater than 1, that node's reference count is simply
decremented and not recursively entered. This does not affect the
deallocation of the original node being deallocated in 2.2; that node is
still deallocated.
3. Every reference has a parent, whether that parent is the root or some
other reference.


> However this conversation is focussing around some samba4 code that does
> a lot of explicit freeing (or stealing), but that is too complicated to
> be re-written.
>

Stealing, in my view of the world, is fine; it simply moves the reference
from one parent to another but does not affect the allocated object at all.

I couldn't follow what samba4 was doing, but I guess maybe the issue is that
samba4 assumes that it can actually free the memory of an allocated object
(i.e. free the actual "inode") even if there are multiple references (links)
to that object (inode), leaving dangling references (which shouldn't be
possible in the "hard link" comparison). If that's the case, it seems like a
very difficult-to-maintain scenario, but there's little that can be done to
make the situation better without rewriting the applicable samba4 code.

Derrell