[CRIU] [PATCH v2 3/3] aio: Restore aio ring content

[Pavel Emelyanov]

On 03/21/2016 03:22 PM, Kirill Tkhai wrote:
> 
> 
> On 21.03.2016 15:10, Pavel Emelyanov wrote:
>> On 03/21/2016 03:02 PM, Kirill Tkhai wrote:
>>>
>>>
>>> On 21.03.2016 13:15, Pavel Emelyanov wrote:
>>>> On 03/21/2016 01:10 PM, Kirill Tkhai wrote:
>>>>
>>>>>>> I'm going to add plugin to parasite_check_aios(), and to wait inflight requests
>>>>>>> from there.
>>>>>>>  
>>>>>>>> Anyway, I don't think treating aio ring buffer as regular anonymous memory
>>>>>>>> is good idea.
>>>>>>>
>>>>>>> What do you suggest? Add vma_entry_is_private(entry) | vma_entry_is(entry, VMA_AREA_AIORING)
>>>>>>> every place we used it?
>>>>>>
>>>>>> Not every. My current opinion is that soft-dirty tracking should NOT
>>>>>> be done for AIO rings.
>>>>>
>>>>> So, if we skip AIO on pre-dump, but we will dump it like any other private memory,
>>>>> is this OK for you?
>>>>
>>>> I tend to think it's not, since these are objects with structure. However
>>>> I don't have string arguments against dumping them as raw blobs _provided_
>>>> we check for ring head magic beforehand.
>>>
>>> I don't completely understand you. What is dumping as raw blobs, but not as like memory?
>>
>> By "as raw blobs" I mean just read the contents of the memory byte-by-byte w/o
>> understanding its structure.
>>
>>> Checking of ring head magic make a sense at a restore, but which way should it be used
>>> at dump?
>>
>> I'd say the same -- check magic and go ahead and read ring memory contents starting
>> from the events array. Reading the header as memory doesn't make sense from my pov.
> 
> Since header shares page[0] with events, if we do not dump it, this saves 32 byte only.
> 
> So, anyway, we dump aio ring content in a file separate from private memory? (I'm just
> clarifying before I started rework).

Good question. If we parsed the contents of it, we'd have to save it into separate
image file. But we treat it as 'memory contents'... Let's keep it in pages.img.

-- Pavel