Re: [PATCH 4/4] Handle unconnected DGRAM sockets with buffers in-flight

[Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org