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

[Andrey Vagin]

On Oct 12, 2015 11:18, "Pavel Emelyanov" <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)

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

>
> -- Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151012/69ed3a67/attachment-0001.html>