Dan Smith wrote: > This changes the checkpoint/restart procedure for sockets a bit. The > socket file header is now checkpointed separately from the socket itself, > which allows us to checkpoint a socket without arriving at it from a > file descriptor. Thus, most sockets will be checkpointed as a result > of processing the file table, calling sock_file_checkpoint(fd), which > in turn calls checkpoint_obj(socket). > > However, we may arrive at some sockets while checkpointing other objects, > such as the other end of an AF_UNIX socket with buffers in flight. This > patch just opens that door, which is utilized by the next patch. > > Changes in v2: > - If we attempt to checkpoint an orphan socket, create a struct socket > to adopt it for the purposes of the checkpoint > > Signed-off-by: Dan Smith <danms@xxxxxxxxxx> Looks good ! Did you also address this ? https://lists.linux-foundation.org/pipermail/containers/2009-September/020385.html ----- SH> Yes. On the struct sock. But what will drop the ref on the SH> struct socket? Or has one of your later patches, not yet in SH> ckpt-v17-dev, added that? Or, am I just missing a place where SH> sock_put() will actually sock_release(sk->sk_socket)? Hmm, I see what you mean. I can't find any path where sock_put() will release the struct socket. What's weird is that there is a WARN_ON() in af_unix.c:354 that should get tripped if we call sk_free() when we still have a socket. I don't see that, but now I'm not sure why. Perhaps what we should do is orphan the struct sock before we add it to the hash and then graft it onto a new struct socket before attaching it to a struct file? ----- [The reason sk_free() expects no sk_socket is because the socket at this point must have been released already via proto_ops->release(). The callback is assumed to orphan the socket]. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
