Quoting Dan Smith (danms@xxxxxxxxxx): > 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
