[PATCH 4/4] Handle unconnected DGRAM sockets with buffers in-flight
danms at us.ibm.com
Thu Aug 13 13:39:50 PDT 2009
OL> Hmm.. I think this would break recvfrom() syscall: it eventually
OL> calls unix_dgram_recvmsg(), which grabs the next skb (datagram) in
OL> the queue, and fills in the address of the socket from which the
OL> datagram had been sent (af_unix.c:1672)
Why would that be any different from the normal case of sending from
an unbound socket to a process receiving with recvfrom()?
OL> if (msg->msg_name)
OL> unix_copy_addr(msg, skb->sk);
If you look at unix_copy_addr() it bails if !sk->addr.
OL> The more I think about it, it seems better to also checkpoint
OL> those unconnected sockets that are the source of dgrams. IOW, when
OL> looping through the received skb's of an unconnected dgram socket,
OL> then check the skb->sk of each pending packet, and checkpoint that
OL> socket too.
That will, IMHO, make the restore process a little uglier. I was
thinking more along the lines of saving the address of the skb's
sender (if needed) and doing something like a temporary bind of the
peer before sending the buffer on restore.
IBM Linux Technology Center
email: danms at us.ibm.com
More information about the Containers