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

[Saied Kazemi]

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.

--Saied


On Tue, Jan 20, 2015 at 11:58 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150121/4585cfc4/attachment.html>