[PATCH 1/3] Make sockets proper objhash objects and use checkpoint_obj() on them (v2)
orenl at librato.com
Wed Sep 9 16:02:13 PDT 2009
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 at us.ibm.com>
Looks good !
Did you also address this ?
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].
More information about the Containers