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