[CRIU] [PATCH] Get rid of " (deleted)" in symlink pathnames

[Pavel Emelyanov]

On 01/20/2015 10:17 PM, Saied Kazemi wrote:
> It's in read_fd_link() called by fixup_aufs_vma_fd() called by vma_get_mapfile().
> 
> I could not use strip_deleted() because its argument is a pointer to struct fd_link.
> 
> Below is a snippet listing of /proc/<pid>map_files for Nginx-streaming.  You see the AUFS
> branch names exposed (which we handle) and then you see "/dev/zero (deleted)".
> 
> By the way, /dev/zero isn't really deleted but I think because it's mmap()'ed as both shared
> and writable (a strange combination), we get " (deleted)" appended to it by the kernel.

Ah, I see. The "/dev/zero (deleted)" is most likely the MAP_SHARED | MAP_ANONYMOUS mapping.
It has nothing to do with files, just kernel manages shared anon mappings with such fake
files.

We detect such beasts with the is_anon_shmem_map() call further in the parse_smaps() and
stripping of the "(deleted)" is typically not required there.

It looks like we need to check for the file being such _before_ trying to fixup aufs path,
not after as we do now.

> ...
> lr-------- 1 root root 64 Jan 20 11:07 7fc5c5840000-7fc5c5863000 -> /var/lib/docker/aufs/diff/3b363fd9d7dab4db9591058a3f43e806f6fa6f7e2744b63b2df4b84eadb0685a/lib/x86_64-linux-gnu/ld-2.19.so <http://ld-2.19.so>
> lrw------- 1 root root 64 Jan 20 11:07 7fc5c5a5f000-7fc5c5a60000 -> /dev/zero (deleted)
> lr-------- 1 root root 64 Jan 20 11:07 7fc5c5a62000-7fc5c5a63000 -> /var/lib/docker/aufs/diff/3b363fd9d7dab4db9591058a3f43e806f6fa6f7e2744b63b2df4b84eadb0685a/lib/x86_64-linux-gnu/ld-2.19.so <http://ld-2.19.so>
> ...
> 
> --Saied
> 
> 
> 
> On Mon, Jan 19, 2015 at 2:04 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
> 
>     On 01/16/2015 11:45 PM, Saied Kazemi wrote:
>     > The kernel (see fs/dcache.c) appends the string " (deleted)" to a deleted
>     > dentry pathname.  We need to remove the string when reading a symlink
>     > that contains it (e.g., symlinks in /proc/<pid>/map_files).
> 
>     Saied, in which function (or calltrace) do you see the "(deleted)" suffix?
>     We tried to address this, we have a function called strip_deleted() which
>     does exactly this, but it looks like we haven't fixed all the cases where
>     this suffix appears.
> 
>     > Signed-off-by: Saied Kazemi <saied at google.com <mailto:saied at google.com>>
> 
>     Thanks,
>     Pavel
> 
>