Re: [PATCH 1/3] Make sockets proper objhash objects and use checkpoint_obj() on them (v2)

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Dan Smith (danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
> SH> I'm sure I sound like an idiot, but... at restore, a socket will
> SH> be created for sk now.  Is that a problem?  I don't see where
> SH> sk_free() will cause that sock to be freed, and you are not
> SH> attaching it do a file whose close would cause it to be
> SH> released...
> 
> In the regular socket code, the reference that is taken during
> allocation is assumed to be for the owning object (the file).  So,
> they don't take another ref when they actually attach it to a file.
> 
> The objhash assumes that for all objects on restore, the allocation
> routine for the object has already incremented the reference count for
> it as the owner.  If you look at restore_obj() it drops the ref count
> right after stuffing the object in the hash because the act of
> insertion grabs a reference.  On checkpoint, this is the reference for
> the hash.  On restore, it would be redundant because it is the first
> owner (not a file, etc).
> 
> My code takes *another* reference when it attaches to a file, if
> appropriate.  In the case of the adopted socket, only the objhash
> holds a reference to it, so unless it was joined to a peer, it will be
> freed when the objhash does its final obj_ref_drop() at tear-down
> time.

Yes.  On the struct sock.  But what will drop the ref on the struct
socket?  Or has one of your later patches, not yet in ckpt-v17-dev,
added that?  Or, am I just missing a place where sock_put() will
actually sock_release(sk->sk_socket)?

-serge