mirror of
https://github.com/checkpoint-restore/criu
synced 2025-08-22 01:51:51 +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
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…
x
Reference in New Issue
Block a user