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

[Stanislav Kinsburskiy]

15.12.2015 10:22, 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.
>

Ok, I'll check.

>>>> 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.

I thing I got it.
What you described is the first way. Because to call ioctl, process have 
to have some private autofs information.
If this will be done from post_open() in pipes.c, then this private 
autofs information have to be associated with pipe fdinfo_list_entry or 
struct pipe_info (probably, latter is a way better).
Ok, I'll implement it this way.

> -- Pavel