<div dir="ltr">OK, I reworked fixup_aufs_vma_fd() to let core CRIU logic handle entries that do not point inside AUFS branches. You should have already received the patch in a separate email already. Please ignore this one.<div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 11:58 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 01/20/2015 10:17 PM, Saied Kazemi wrote:<br>
> It's in read_fd_link() called by fixup_aufs_vma_fd() called by vma_get_mapfile().<br>
><br>
> I could not use strip_deleted() because its argument is a pointer to struct fd_link.<br>
><br>
> Below is a snippet listing of /proc/<pid>map_files for Nginx-streaming. You see the AUFS<br>
> branch names exposed (which we handle) and then you see "/dev/zero (deleted)".<br>
><br>
> By the way, /dev/zero isn't really deleted but I think because it's mmap()'ed as both shared<br>
> and writable (a strange combination), we get " (deleted)" appended to it by the kernel.<br>
<br>
</span>Ah, I see. The "/dev/zero (deleted)" is most likely the MAP_SHARED | MAP_ANONYMOUS mapping.<br>
It has nothing to do with files, just kernel manages shared anon mappings with such fake<br>
files.<br>
<br>
We detect such beasts with the is_anon_shmem_map() call further in the parse_smaps() and<br>
stripping of the "(deleted)" is typically not required there.<br>
<br>
It looks like we need to check for the file being such _before_ trying to fixup aufs path,<br>
not after as we do now.<br>
<br>
> ...<br>
> lr-------- 1 root root 64 Jan 20 11:07 7fc5c5840000-7fc5c5863000 -> /var/lib/docker/aufs/diff/3b363fd9d7dab4db9591058a3f43e806f6fa6f7e2744b63b2df4b84eadb0685a/lib/x86_64-linux-gnu/<a href="http://ld-2.19.so" target="_blank">ld-2.19.so</a> <<a href="http://ld-2.19.so" target="_blank">http://ld-2.19.so</a>><br>
<span class="">> lrw------- 1 root root 64 Jan 20 11:07 7fc5c5a5f000-7fc5c5a60000 -> /dev/zero (deleted)<br>
</span>> lr-------- 1 root root 64 Jan 20 11:07 7fc5c5a62000-7fc5c5a63000 -> /var/lib/docker/aufs/diff/3b363fd9d7dab4db9591058a3f43e806f6fa6f7e2744b63b2df4b84eadb0685a/lib/x86_64-linux-gnu/<a href="http://ld-2.19.so" target="_blank">ld-2.19.so</a> <<a href="http://ld-2.19.so" target="_blank">http://ld-2.19.so</a>><br>
> ...<br>
><br>
> --Saied<br>
<span class="">><br>
><br>
><br>
> On Mon, Jan 19, 2015 at 2:04 AM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>>> wrote:<br>
><br>
> On 01/16/2015 11:45 PM, Saied Kazemi wrote:<br>
> > The kernel (see fs/dcache.c) appends the string " (deleted)" to a deleted<br>
> > dentry pathname. We need to remove the string when reading a symlink<br>
> > that contains it (e.g., symlinks in /proc/<pid>/map_files).<br>
><br>
> Saied, in which function (or calltrace) do you see the "(deleted)" suffix?<br>
> We tried to address this, we have a function called strip_deleted() which<br>
> does exactly this, but it looks like we haven't fixed all the cases where<br>
> this suffix appears.<br>
><br>
</span>> > Signed-off-by: Saied Kazemi <<a href="mailto:saied@google.com">saied@google.com</a> <mailto:<a href="mailto:saied@google.com">saied@google.com</a>>><br>
><br>
> Thanks,<br>
> Pavel<br>
><br>
><br>
<br>
</blockquote></div><br></div>