[CRIU] problem restoring unix queues?

[Pavel Emelyanov]

On 07/18/2015 02:17 AM, Tycho Andersen wrote:
> On Fri, Jul 17, 2015 at 07:13:55PM +0300, Pavel Emelyanov wrote:
>> On 07/17/2015 05:33 PM, Tycho Andersen wrote:
>>> Hi all,
>>>
>>> Sometimes I see something like:
>>>
>>> (00.095976)     77: Error (sk-queue.c:238): Failed to send packet: Resource temporarily unavailable
>>>
>>> when restoring (full log here: http://paste.ubuntu.com/11893011/).
>>>
>>> The sk-queues.img is: http://paste.ubuntu.com/11893015/ so I don't
>>> /think/ it should be filling the buffer, so I'm not sure why we'd get
>>> EAGAIN.
>>>
>>> Thoughts?
>>
>> Is it stream or datagram socket? AFAIK the EAGAIN is only reported when
>> you hit socket buffer limit, but we try to raise one :\
> 
> Assuming the "id" is the same as "id_for" above, it looks like it is
> SOCK_DGRAM (output from unixsk.img):
> 
>         {
>             "id": 14, 
>             "ino": 16798503, 
>             "type": 2, # SOCK_DGRAM == 2
>             "state": 7, 
>             "flags": "0x80802", 
>             "uflags": "0x0", 
>             "backlog": 0, 
>             "peer": 0, 
>             "fown": {
>                 "uid": 0, 
>                 "euid": 0, 
>                 "signum": 0, 
>                 "pid_type": 0, 
>                 "pid": 0
>             }, 
>             "opts": {
>                 "so_sndbuf": 212992, 
>                 "so_rcvbuf": 16777216, 
>                 "so_snd_tmo_sec": 0, 
>                 "so_snd_tmo_usec": 0, 
>                 "so_rcv_tmo_sec": 0, 
>                 "so_rcv_tmo_usec": 0, 
>                 "reuseaddr": true, 
>                 "so_priority": 0, 
>                 "so_rcvlowat": 1, 
>                 "so_mark": 0, 
>                 "so_passcred": true, 
>                 "so_passsec": true, 
>                 "so_dontroute": false, 
>                 "so_no_check": false
>             }, 
>             "name": "L3J1bi9zeXN0ZW1kL2pvdXJuYWwvc29ja2V0AA==\n", 
>             "file_perms": {
>                 "mode": 49590, 
>                 "uid": 0, 
>                 "gid": 0
>             }
>         }, 
> 
> Based on my read of the criu/kernel sources, we're setting
> sk->sk_sndbuf, while the kernel source in unix_dgram_sndmsg is checking
> sk->sk_receive_queue for sending EAGAIN; since we pass the backlog of
> 0 to listen() (viz. above), I guess this is what's causing the
> problem? Seems like a backlog of 0 must be wrong, since the queue is
> of non-zero length.

Wait a second, if you send packets to socket it cannot be in listen
state. Moreover, according to your image the state of the socket is
7 which is CLOSED :)

-- Pavel

-- Pavel