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

[Stanislav Kinsburskiy]

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.

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