[CRIU] [PATCH v5 3/5] Try to include userfaultfd with criu (part 1)

[Pavel Emelyanov]

On 03/18/2016 12:19 AM, Adrian Reber wrote:
> On Thu, Mar 17, 2016 at 03:56:52PM +0300, Pavel Emelyanov wrote:
>>>> In particular, the call to collect_remaps_and_regfiles() should not be
>>>> here as it picks up info about files, not memory.
>>>
>>> Not knowing the complete details it seems it is necessary as mm.img
>>> in my case contains exe_file_id: 2, which can be resolved with the
>>> information from reg-files.img pointing to the actual binary. Now,
>>> thinking about it, it seems irrelevant for lazy pages to know which
>>> page belongs to which binary. I might be getting to the point where I
>>> understand what you want. I will continue to get this resolved.
>>
>> Great!
>>
>> Don't hesitate asking more question if you have, all these interdependencies
>> between images and objects are really tricky.
> 
> I am down to this:
> 
>         check_img_inventory();
>         /* Allocate memory for task_entries */
>         prepare_task_entries();
>         prepare_pstree();
>         struct rst_info *ri = rsti(root_item);
> 
> prepare_task_entries() seems to allocate the necessary memory structures
> for prepare_pstree(). Without prepare_task_entries() prepare_pstree()
> just segfaults as the pointers prepare_task_entries() is using are
> partially still NULL. Would this be acceptable? 

For the beginning -- yes. Though you may avoid using pstree for lazy daemon.
AFAIU you need to do (part of) prepare_mm_pid() to read the list of vmas into
somewhere with pid on board to do correct pid to list of vmas mapping.

For this allocating an empty pstree item by alloc_pstree_item() should be
enough. Hm... Probably you'd need to lookup pstree item by pid. Then the
lookup_create_item() is the call for you.

> Maybe it is easier if I send the complete patch for review.

Sure!

-- Pavel