<div dir="ltr">Yes, that could happen although only for AUFS (because we explicitly check opts.aufs). Any suggestions on how to make it accept root mount id *only* for the "bad" entries in map_files?<div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 9:52 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/08/2014 10:36 AM, Saied Kazemi wrote:<br>
> Here is an explanation of the problem. As you know, the AUFS implementation in the kernel has a bug. Specifically, by pointing inside AUFS branches, the file descriptors of links in /proc/<pid>/map_files create two problems (these file descriptors are saved by ma_get_mapfile() in vma->vm_file_fd):<br>
><br>
> 1. When doing readlink() on them, the path inside the branch is not accessible in the mount namespace.<br>
><br>
> 2. When reading their /proc/<pid>/fdinfo, the mnt_id value corresponds to a mountpoint that is not visible in the mount namespace.<br>
><br>
> The patch that we applied earlier addressed issue 1 above. Attached is a patch for issue 2 if we need a quick workaround<br>
> but I would like a better solution. The patch has a special provision for AUFS to return the root mountpoint if mnt_id cannot be found.<br>
><br>
> What do you guys think?<br>
<br>
</span>I'm not sure this is the correct way to go. With this we can<br>
erroneously succeed the situation when a file is really opened<br>
outside of the container and is having an "invisible" mnt_id.<br>
<br>
Thanks,<br>
Pavel<br>
<br>
</blockquote></div><br></div>