[CRIU] [RFC PATCH 4/5] autofs: restore procedure introduced

[Pavel Emelyanov]

On 11/24/2015 02:20 PM, Stanislav Kinsburskiy wrote:
> 
> 
> 24.11.2015 11:58, Pavel Emelyanov пишет:
>>>>> +struct autofs_info_s {
>>>>> +	int pipe_fd;
>>>>> +	const char *mnt_path;
>>>>> +	struct autofs_info_s *next;
>>>>> +};
>>>>> +
>>>>> +struct autofs_service_s {
>>>>> +	int pgrp;
>>>>> +	struct autofs_info_s *mnt_info;
>>>>> +	struct autofs_service_s *next;
>>>>> +} *automount;
>>>>> +
>>>>> +int autofs_fixup_owner(struct autofs_info_s *info)
>>>>> +{
>>>>> +	int autofs_fd, mnt_fd, err = -1;
>>>>> +	struct autofs_dev_ioctl param;
>>>>> +
>>>>> +	autofs_fd = open("/dev/autofs", O_RDONLY);
>>>>> +	if (autofs_fd == -1) {
>>>>> +		pr_perror("failed to open /dev/autofs");
>>>>> +		return -1;
>>>>> +	}
>>>>> +
>>>>> +	mnt_fd = open(info->mnt_path, O_RDONLY | O_DIRECTORY);
>>>>> +	if (mnt_fd == -1) {
>>>>> +		pr_perror("failed to open %s", info->mnt_path);
>>>>> +		goto close_fd;
>>>>> +	}
>>>>> +
>>>>> +	init_autofs_dev_ioctl(&param);
>>>>> +	err = ioctl(mnt_fd, AUTOFS_IOC_CATATONIC, 0);
>>>>> +	if (err == -1) {
>>>>> +		pr_perror("failed to set mount point catatonic");
>>>>> +		goto close_mnt_fd;
>>>>> +
>>>>> +	}
>>>>> +
>>>>> +	init_autofs_dev_ioctl(&param);
>>>>> +	param.ioctlfd = mnt_fd;
>>>>> +	param.setpipefd.pipefd = info->pipe_fd;
>>>> The info->pipe_fd is set by autofs_mount() and the fd value is purely
>>>> parsed from options. Who and when creates this very fd?
>>> The pipe itself belongs to automount process and restored as any other fd.
>>> Yes, we are probably lucky, that automount doesn't close write end of
>>> the pipe, which is sent to the kernel.
>> I still don't get it. CRIU would close pipe's write end once ->open is
>> called, so in ->post_open the kernel part of the pipe should not be
>> available.
>>
>> Can you write the sequence of steps that lead to this particular place
>> in the code and show _where_ the write end of the pipe is (was) created?
>>
> 
> It's very simple: user space process (automount) contains _both_ ends of 
> the pipe. One of this ends is also used by the kernel.
> IOW, pipe is reopened, as any other, and write end is not closed.
> That's a pure luck, that automount process doesn't close write end.

OK, but then you should add a check for the write-end being in the process.

> In case of systemd, this end is closed. And this case have to be covered 
> as well. There should be some way, how to find the _read_ end of kernel 
> pipe. If you know one, hint will be highly appreciated.

No way to get this info, kernel should be patched to at least report
pipe inode number.

> But I suggest to fix this stuff on top of the series. While the series 
> requires a check, that process contains both ends (like automount does).
> 
> Does it suits you?

Yes. But I wonder how you will _safely_ distinguish which process is
attached to autofs mount. Doing this by pgrp only doesn't look OK.

-- Pavel