[CRIU] zdtm thp_disable test fails on VZ7

[Pavel Tikhomirov]

Running criu zdtm on VZ7 I got error in thp_disable test:

======================= Run zdtm/static/thp_disable in h 
=======================
Start test
./thp_disable --pidfile=thp_disable.pid --outfile=thp_disable.out
make: *** [thp_disable.pid] Error 1
  Test zdtm/static/thp_disable FAIL at [u'make', 
u'--no-print-directory', u'-C', u'zdtm/static', u'thp_disable.pid']
Test output: ================================
03:10:21.643:    36: Fetch existing flags/adv
03:10:21.644:    36: ERR: get_smaps_bits.c:122: VmFlags not found for 
7f11affca000 (errno = 2 (No such file or directory))
03:10:21.644:    35: ERR: test.c:316: Test exited unexpectedly with code 255

https://ci.openvz.org/job/CRIU/job/CRIU-virtuozzo/job/criu-dev/4719/consoleFull

Sorry but I failed to find the initial patch mail for criu-dev commit 
which triggers these problem for me: 8d7aac573 ("zdtm: add test for 
prctl(PR_SET_THP_DISABLE)") So sending these without inreply.

I managed to reproduce the initial problem with small programm:

[root at silo ~]# cat mmap_addr.c
#include <stdio.h>
#include <sys/mman.h>

int main()
{
	void *area;

	scanf("%*s");
	area = mmap(NULL, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE | 
MAP_ANONYMOUS, -1, 0);
	if (area == MAP_FAILED) {
		perror("mmap");
		return 1;
	}

	printf("area == %p\n", area);
	scanf("%*s");
	return 0;
}

I start it and connect with strace, while hanging on first scanf, next I 
enter some text and if calls mmap:

[root at silo ~]# ./mmap_addr
f
area == 0x7f9808bbf000

[root at silo ~]# strace -p 230787
strace: Process 230787 attached
read(0, "f\n", 1024)                    = 2
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f9808bbf000
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f9808bbe000
write(1, "area == 0x7f9808bbf000\n", 23) = 23
read(0,

[root at silo ~]# cat /proc/230787/smaps | grep 7f9808bbe000
7f9808bbe000-7f9808bc3000 rw-p 00000000 00:00 0
[root at silo ~]# cat /proc/230787/smaps | grep 7f9808bbf000
[root at silo ~]#

So the start of maped area in smaps is not the same as we see returned 
from syscall, because of second mmap made likely by our old glibc.

Using gdb I stopped on each actual syscall and I see that first mmap was 
right in /proc/pid/smaps (started with returned value), but second call 
changed it.

The question is can we actually rely on the fact that returned address 
from mmap is the beginning of real mapping seeing in /proc/pid/smaps?

-- 
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.