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

[Pavel Emelyanov]

On 12/15/2015 12:34 PM, Stanislav Kinsburskiy wrote:

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

OK, then the way #1.

> If this will be done from post_open() in pipes.c, then this private 

The pipe.c doesn't provide any post_open callbacks. You can allocate
pipe_info in autofs code (you anyway move this structure outside of
pipe.c with patch #14) and call file_desc_add() from autofs code again
providing different desc ops that can sit in autofs code again. No need
to toss pipe.c code heavily.

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

Thanks.