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

[Oren Laadan]

Dan Smith wrote:
> 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()?

The recvfrom() would give wrong result (compared to original execution)
unless the correct socket-of-origin is used.

> 
> 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.
> 

This would mean one socket for all skb's (dgrams), so one address
for all of them. So one result for recvfrom() on restored system
vs multiple different addresses on original system.

Oren.