问题
Testing a MariaDB anomaly of mysqld (10.3 branch) what it does is on startup:
A memory allocation returns ptr=0x7fffe1a00000 for bytes=2097152
Before the madvise syscall, the /proc/{pid}/smap entry is:
7fffe1a00000-7fffe1c00000 rw-s 00000000 00:0f 18481215 /SYSV00000000 (deleted)
Size: 2048 kB
KernelPageSize: 2048 kB
MMUPageSize: 2048 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms de ht sd
After the call:
madvise(ptr, bytes, MADV_DONTDUMP)
The page picks up the dd "don't dump" flags as expected:
7fffe1a00000-7fffe1c00000 rw-s 00000000 00:0f 18481215 /SYSV00000000 (deleted)
Size: 2048 kB
KernelPageSize: 2048 kB
MMUPageSize: 2048 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms de ht dd sd
sometime later just before madvise(ptr, m_size, MADV_DODUMP) the map is the same:
7fffe1a00000-7fffe1c00000 rw-s 00000000 00:0f 18481215 /SYSV00000000 (deleted)
Size: 2048 kB
KernelPageSize: 2048 kB
MMUPageSize: 2048 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms de ht dd sd
The next code is:
madvise(ptr, m_size, MADV_DODUMP)
GDB shows the same values are used:
(gdb) p size
$1 = 2097152
(gdb) p ptr
$2 = (void *) 0x7fffe1a00000
madvise(ptr,size,MADV_DODUMP) is returns -1, errno=EINVAL, and the page map remains the same.
Kernel version:
$ uname -a
Linux 4.18.9-300.fc29.x86_64 #1 SMP Thu Sep 20 02:32:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
For completeness, a strace -fe trace=%memory ... extract from allocation to EINVAL of the same program (different execution):
[pid 6036] shmat(18874431, NULL, 0) = 0x7f6ebda00000
[pid 6036] madvise(0x7f6ebda00000, 2097152, MADV_DONTDUMP) = 0
[pid 6036] mmap(NULL, 2215936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6ebd7e3000
[pid 6036] brk(NULL) = 0x55caa0d76000
[pid 6036] brk(0x55caa0de7000) = 0x55caa0de7000
[pid 6036] brk(NULL) = 0x55caa0de7000
[pid 6036] brk(0x55caa0e38000) = 0x55caa0e38000
[pid 6036] brk(NULL) = 0x55caa0e38000
[pid 6036] brk(0x55caa0e8a000) = 0x55caa0e8a000
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6ebcfe2000
[pid 6036] mprotect(0x7f6ebcfe3000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6039 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6ebc7e1000
[pid 6036] mprotect(0x7f6ebc7e2000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6040 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6ead3ff000
[pid 6036] mprotect(0x7f6ead400000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6041 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eacbfe000
[pid 6036] mprotect(0x7f6eacbff000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6042 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eac3fd000
[pid 6036] mprotect(0x7f6eac3fe000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6043 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eabbfc000
[pid 6036] mprotect(0x7f6eabbfd000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6044 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eab3fb000
[pid 6036] mprotect(0x7f6eab3fc000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6045 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eaabfa000
[pid 6036] mprotect(0x7f6eaabfb000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6046 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6eaa3f9000
[pid 6036] mprotect(0x7f6eaa3fa000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6047 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6ea9bf8000
[pid 6036] mprotect(0x7f6ea9bf9000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6048 attached
[pid 6036] mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6ea93f7000
[pid 6036] mprotect(0x7f6ea93f8000, 8388608, PROT_READ|PROT_WRITE) = 0
strace: Process 6049 attached
[pid 6049] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f6ea13f7000
[pid 6049] munmap(0x7f6ea13f7000, 46174208) = 0
[pid 6049] munmap(0x7f6ea8000000, 20934656) = 0
[pid 6049] mprotect(0x7f6ea4000000, 135168, PROT_READ|PROT_WRITE) = 0
[pid 6036] brk(NULL) = 0x55caa0e8a000
[pid 6036] brk(0x55caa0eab000) = 0x55caa0eab000
[pid 6036] mmap(NULL, 2117632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6ebc5dc000
[pid 6036] munmap(0x7f6ebd7e3000, 2215936) = 0
[pid 6036] brk(NULL) = 0x55caa0eab000
[pid 6036] brk(0x55caa10d5000) = 0x55caa10d5000
[pid 6036] brk(NULL) = 0x55caa10d5000
[pid 6036] brk(0x55caa1118000) = 0x55caa1118000
[pid 6036] brk(NULL) = 0x55caa1118000
[pid 6036] brk(0x55caa115c000) = 0x55caa115c000
[pid 6036] madvise(0x7f6ebda00000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument)
Any clues as to why the EINVAL is returned for madvise(MADV_DODUMP)?
code is: mariadb-10.3 branch
回答1:
de refers to VM_DONTEXPAND, and the kernel explicitly rejects that flag for MADV_DODUMP:
#define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP)
…
case MADV_DODUMP:
if (new_flags & VM_SPECIAL) {
error = -EINVAL;
goto out;
}
new_flags &= ~VM_DONTDUMP;
break;
This check has been present since commit 0103bd16fb90bc741c7a03fd1ea4e8a505abad23 (“mm: prepare VM_DONTDUMP for using in drivers”) in 2012.
This mapping probably comes from hugetlbfs (hugetlbfs_file_mmap in fs/hugetlbfs/inode.c) because the ht bit is set as well.
来源：https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit