[CRIU] [PATCH] fsnotify: Use longest mount point for inotify watchee

[Pavel Emelyanov]

On 10/12/2015 11:31 AM, Andrey Vagin wrote:
> 
> On Oct 12, 2015 11:18, "Pavel Emelyanov" <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
>>
>> On 10/12/2015 11:14 AM, Cyrill Gorcunov wrote:
>> > On Mon, Oct 12, 2015 at 11:06:32AM +0300, Pavel Emelyanov wrote:
>> >> On 10/10/2015 11:07 AM, Cyrill Gorcunov wrote:
>> >>> In debian-8 container we faced the problem -- systemd
>> >>> creates nested mount namespaces and inotify watchee
>> >>> are resolved into a path which is inaccessbile on
>> >>> restore (because we're operating in task's mount
>> >>> namespace). So here is a dirty hack for now -- choose
>> >>> the widest mount point as a reference. The proper
>> >>> fix requires kernel patching.
>> >>
>> >> How about Andrey's patch that saved mnt-id for an inotify?
>> >
>> > This won't work on its own. Please look at the second patch
>> > I send into the reply of this one. We need mnt_id but the
>> > path may be inaccessible during the restore because the
>> > restore comes in another mount namespace where the former
>> > path is no longer accessbile.
>>
>> But we do know the namespace the path come from, why do we ever
>> _guess_ anything instead of just going to that ns and opening
>> the file there?
> 
> Here is a problem that we can open a handle from a bind-mount where this file is unavailable by path.
> 
> For example:
> 
> mount /dev/xxx /
> mount --bind /var/yyy /zzz
> inotify_add_watch("/test")
> Read handle from /proc/pid/fdinfo/inotify_fd
> FD = open_handlat("/zzz", handle)

You call open_handle_at() on /zzz because the device /dev/xxx
is shown for both, / and /zzz, right?

> readlink /proc/pid/fd/FD
> /zzz/test

Heh :) But the /zzz/test is non-existing path, is it? Isn't it a
kernel issue? I mean -- why does kernel report this path? When
I do open_handle_at() and the "test" dentry is created where does
it get connected to?

-- Pavel