[CRIU] [PATCH v3 1/2] unix: Add support for restoring receive queue for unix DGRAM sockets

[Kirill Tkhai]

On 04.12.2015 15:43, Pavel Emelyanov wrote:
> 
>> @@ -1133,6 +1133,40 @@ static int open_unixsk_standalone(struct unix_sk_info *ui)
>>  
>>  		close(sks[1]);
>>  		sk = sks[0];
>> +	} else if (ui->ue->type == SOCK_DGRAM) {
> 
> I saw your response about SOCK_STREAM sockets in the previous version of
> the patch, but still want to get back to this discussion.
> 
> I'm not sure that the problem doesn't exist for stream sockets as you
> say. What happens if we do socketpair(PF_UNIX, SOCK_STREAM), then send 
> data from sk[0] to sk[1] and then close(sk[0])? Is this supported by
> CRIU, do we have such a test and which code handles the sk[1]'s queue 
> restore?

SOCK_STREAM is supported in TCP_ESTABLISHED case in the same function.
I don't have any information about if there is a test.
 
> -- Pavel
> 
>> +		struct sockaddr_un addr;
>> +		int sks[2];
>> +
>> +		if (socketpair(PF_UNIX, ui->ue->type, 0, sks) < 0) {
>> +			pr_perror("Can't create socketpair");
>> +			return -1;
>> +		}
>> +
>> +		sk = sks[0];
>> +		addr.sun_family = AF_UNSPEC;
>> +
>> +		/*
>> +		 * socketpair() assigns sks[1] as a peer of sks[0]
>> +		 * (and vice versa). But in this case (not zero peer)
>> +		 * it's impossible for other sockets to connect
>> +		 * to sks[0] (see unix_dgram_connect()->unix_may_send()).
>> +		 * The below is hack: we use that connect with AF_UNSPEC
>> +