[CRIU] [PATCH v2 06/15] unix: Add sender_ino of packets and socket

Pavel Emelyanov xemul at virtuozzo.com
Wed Jun 1 03:45:17 PDT 2016


On 05/31/2016 04:03 PM, Kirill Tkhai wrote:
> 
> 
> On 31.05.2016 14:02, Pavel Emelyanov wrote:
>> On 05/30/2016 03:30 PM, Kirill Tkhai wrote:
>>>
>>>
>>> On 30.05.2016 14:40, Pavel Emelyanov wrote:
>>>> On 05/27/2016 04:06 PM, Kirill Tkhai wrote:
>>>>> Add optional field "sender_ino" to packet and socket proto.
>>>>>
>>>>> Signed-off-by: Kirill Tkhai <ktkhai at virtuozzo.com>
>>>>> ---
>>>>>  images/sk-packet.proto |    1 +
>>>>>  images/sk-unix.proto   |    2 ++
>>>>>  2 files changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/images/sk-packet.proto b/images/sk-packet.proto
>>>>> index 10ef5c9..2e1c8b3 100644
>>>>> --- a/images/sk-packet.proto
>>>>> +++ b/images/sk-packet.proto
>>>>> @@ -1,4 +1,5 @@
>>>>>  message sk_packet_entry {
>>>>>  	required uint32		id_for		= 1;
>>>>>  	required uint32		length		= 2;
>>>>> +	optional uint32		sender_ino	= 3;
>>>>
>>>> This is understood.
>>>>
>>>>>  }
>>>>> diff --git a/images/sk-unix.proto b/images/sk-unix.proto
>>>>> index aa2bcf7..7b71ebf 100644
>>>>> --- a/images/sk-unix.proto
>>>>> +++ b/images/sk-unix.proto
>>>>> @@ -45,4 +45,6 @@ message unix_sk_entry {
>>>>>  	 * Relative socket name may have prefix.
>>>>>  	 */
>>>>>  	optional string			name_dir	= 14;
>>>>> +
>>>>> +	optional uint32			sender_ino	= 15;
>>>>
>>>> Why do you need this new number on socket entry?
>>>
>>> This allows to understand that a DGRAM socket is not a promiscuous.
>>> If so, we may set a sender as our queuer (see sk_queuer()).
>>>
>>> Otherwise, we would have to do additional work on restore. We would
>>> have to scan skb queue to understand if it's promiscuous.
>>>
>>> Using unix_sk_entry::sender_ino, we easily mark the most sockets as
>>> "having queuer", and skip them on "resolve senders" stage.
>>> See resolve_unix_peers() changes.
>>
>> OK. From my perspective you don't need this in image. During resolve_unix_peers()
>> we scan all the sockets, you can add analysis of the packets and find out
>> whether the socket is no-queuer or not.
> 
> I think this trick may speed-up restore in some way. If you are worrying about
> using of space for that, I can add USK_HAS_SENDER flag instead. Is it OK for you?

No, please. The information in sk-packet.img is enough to decide what
kind of sender restore we have. We pull in this image into memory anyway.

-- Pavel



More information about the CRIU mailing list