mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-01-23 02:14:37 +00:00
Ignore mnt_id value for AUFS file descriptors.
Starting with version 3.15, the kernel provides a mnt_id field in
/proc/<pid>/fdinfo/<fd>. However, the value provided by the kernel for
AUFS file descriptors obtained by opening a file in /proc/<pid>/map_files
is incorrect.
Below is an example for a Docker container running Nginx. The mntid
program below mimics CRIU by opening a file in /proc/1/map_files and
using the descriptor to obtain its mnt_id. As shown below, mnt_id is
set to 22 by the kernel but it does not exist in the mount namespace of
the container. Therefore, CRIU fails with the error:
"Unable to look up the 22 mount"
In the global namespace, 22 is the root of AUFS (/var/lib/docker/aufs).
This patch sets the mnt_id of these AUFS descriptors to -1, mimicing
pre-3.15 kernel behavior.
$ docker ps
CONTAINER ID IMAGE ...
3850a63ee857 nginx-streaming:latest ...
$ docker exec -it 38 bash -i
root@3850a63ee857:/# ps -e
PID TTY TIME CMD
1 ? 00:00:00 nginx
7 ? 00:00:00 nginx
31 ? 00:00:00 bash
46 ? 00:00:00 ps
root@3850a63ee857:/# ./mntid 1
open("/proc/1/map_files/400000-4b8000") = 3
cat /proc/49/fdinfo/3
pos: 0
flags: 0100000
mnt_id: 22
root@3850a63ee857:/# awk '{print $1 " " $2}' /proc/1/mountinfo
87 58
103 87
104 87
105 104
106 104
107 104
108 87
109 87
110 87
111 87
root@3850a63ee857:/# exit
$ grep 22 /proc/self/mountinfo
22 21 8:1 /var/lib/docker/aufs /var/lib/docker/aufs ...
44 22 0:35 / /var/lib/docker/aufs/mnt/<ID> ...
$
Signed-off-by: Saied Kazemi <saied@google.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This commit is contained in:
parent
29673d42a9
commit
e3fec5f8eb
2 changed files with 13 additions and 2 deletions
10
proc_parse.c
10
proc_parse.c
|
|
@ -543,7 +543,15 @@ int parse_smaps(pid_t pid, struct vm_area_list *vma_area_list)
|
|||
vma_area->e->status |= VMA_FILE_SHARED;
|
||||
}
|
||||
|
||||
if (get_fd_mntid(vma_area->vm_file_fd, &vma_area->mnt_id))
|
||||
/*
|
||||
* We cannot use the mnt_id value provided by the kernel
|
||||
* for vm_file_fd if it is an AUFS file (the value is
|
||||
* wrong). In such a case, fixup_aufs_vma_fd() has set
|
||||
* mnt_id to -1 to mimic pre-3.15 kernels that didn't
|
||||
* have mnt_id.
|
||||
*/
|
||||
if (vma_area->mnt_id != -1 &&
|
||||
get_fd_mntid(vma_area->vm_file_fd, &vma_area->mnt_id))
|
||||
return -1;
|
||||
} else {
|
||||
/*
|
||||
|
|
|
|||
|
|
@ -262,7 +262,8 @@ err:
|
|||
|
||||
/*
|
||||
* AUFS support to compensate for the kernel bug
|
||||
* exposing branch pathnames in map_files.
|
||||
* exposing branch pathnames in map_files and providing
|
||||
* a wrong mnt_id value in /proc/<pid>/fdinfo/<fd>.
|
||||
*
|
||||
* If the link points inside a branch, save the
|
||||
* relative pathname from the root of the mount
|
||||
|
|
@ -304,6 +305,8 @@ int fixup_aufs_vma_fd(struct vma_area *vma)
|
|||
return -1;
|
||||
}
|
||||
|
||||
/* tell parse_smap() not to call get_fd_mntid() */
|
||||
vma->mnt_id = -1;
|
||||
return len;
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue