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. -- Dan Smith IBM Linux Technology Center email: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
