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

[Saied Kazemi]

By the way, I forgot to mention in my previous email that with this patch
we can revert the "Fix AUFS pathname handling when branch is not exposed"
patch (commit 490ca71866).

--Saied


On Wed, Jan 21, 2015 at 3:25 PM, Saied Kazemi <saied at google.com> wrote:

> 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/ee8382b6/attachment-0001.html>