[CRIU] [PATCH v3 00/16] AutoFS mounts migration support

[Pavel Emelyanov]

On 12/15/2015 01:03 AM, Stanislav Kinsburskiу wrote:
> 
> 14 дек. 2015 г. 8:03 PM пользователь Pavel Emelyanov <xemul at parallels.com> написал:
>>
>> On 12/14/2015 07:25 PM, Stanislav Kinsburskiy wrote: 
>>> So, let me try summarize all we have discussed here so far: 
>>>
>>> 1) Helpers: add_to_string_vargs and and construct string. You don't like 
>>> them? They are more efficient, then add_options and friend, BTW. And 
>>> fully generic. 
> 
> You didn't anwer on this question.

If you put those routines in util.c and find one more user for them -- OK.
But at current state of this patchset the attach_option() just works.

>>> 2) Autofs migration data have to be represented by optional autofs 
>>> structure in mount protobuf format. 
>>
>> Looks like yes. 
>>
>>> 3) Are we trying to preserve original pipe write fd on restore? If yes, 
>>> then we need "used" list. 
>>
>> Kernel remembers this fd and shows on in options, so yes, this number 
>> must be preserved. 
>>
>>> 4) Regardless of presence or absence of opened write end, some routing 
>>> to search for file descriptor list entry is required: either to masrk 
>>> write end or to clone read end. 
>>
>> Probably. I saw it like -- you know the pipe_id that sits in the kernel, 
>> so on restore you just 'create' this pipe_info and add respective fd entry 
>> to the proper task. 
>>
>>> 5) "Clone file descriptor list entry" helper is required to construct 
>>> write end is absent. 
>>
>> Probably yes. 
>>
>>> 6) Which way should autofs restore follow: use some artificial objects, 
>>> handled after all files are opened or callbacks between autofs and 
>>> pipes? In case of the latter, some callback have to be put on pipe_entry 
>>> structure, so it can be called in new post_open() for pipes. 
>>
>> From my perspective taking a task that should restore write end and 
>> adding to its rst_info a file desc entry which refers to the needed 
>> pipe is the easiest way to go. 
>>
> 
> I don't really get it.
> So, first of all, they could be many. Thus it will be a list.

Yes.

> There can be different ways to proceed:
> 1) existent (or created) write descriptor is connected somehow to autofs data 
>    (private pointer, for example, marked as used by autofs, and on post_open()
>    callback from pipes.c it calls something like autofs_fixup(), passing there
>    it'private data.
> 2) each process has a list of some objects (on rst_info), representing autofs
>    mount, which process iterates _after_ all files are opened. In this case this
>    object can be of any type and not connected to file descriptors at all. It
>    have to represent autofs data and have information about write descriptor 
>    number to pass it ot kernel and close, if necessary.
> 3) introducing some "file desc entry" per each mount, put them in separated list,
>    and iterate in generic fd open cycle (actually, almost the same way I made it
>    initially).
> 
> Which one do you prefer?

I'm not sure I understand those 3 ways correctly :( Let me rephrase what I have
in mind.

The goal is -- you need to attach a pipe to an autofs mount. 

The initial state is -- at restore time two objects exist: this exact pipe's 
read end's pipe_info and fdinfo_list_entry. Probably there are two more --
a write end's pipe_info and fdinfo_list_entry.

The constraint is -- not any task can call ioctl that attached pipe to mountpoint.

So to achieve the goal I propose to

1. Find the pstree_entry that can call attaching ioctl
2. Create pipe_info that corresponds to write end of the pipe and add one to
   the pipe_info of the read end. There can be already such entry, but that's
   OK, pipe.c knows this can happen.
3. Create fdinfo_list_entry representing a write end of the pipe and queue it
   to the pstree from step 1 fds list tail. Yet again -- there can already be
   such thing, but that's also OK, files.c can handle it. The post_open callback
   for such entry will call ioctl and close the descriptor.

-- Pavel