[CRIU] zdtm thp_disable test fails on VZ7

Dmitry Safonov 0x7f454c46 at gmail.com
Fri Feb 8 04:27:43 MSK 2019


+CC back list and Andrey - seems like I hit the wrong button on reply, hehe.

On 2/6/19 8:13 PM, Mike Rapoport wrote:
> On Wed, Feb 06, 2019 at 04:57:41PM +0000, Dmitry Safonov wrote:
>> Looking at vma_merge() - I don't see anything to force unmerge.
>> Except additional clone(), hehe.
>
> madvise()

Huh? I've probably missed some part of man page, which exactly call would force
unmerge without changing policy/prot/rights?
I saw that clone() would prevent merging if vma is referenced in both
places, IIRC.

On Thu, 7 Feb 2019 at 12:35, Pavel Tikhomirov <ptikhomirov at virtuozzo.com> wrote:
> >> BTW:
> >> https://github.com/checkpoint-restore/criu/pull/604/commits/0182eb984d80df3f93c9f344161e373aa4f1ff9f
>
> These helps the test to pass on VZ7, thanks Dima!
>
> I've also found where second mmap comes from, for my mmap_addr.c it came
> from "printf("area == %p\n", area);" line, in initial test we also do
> some printing just after mmap.

Yeah, it also seemed to me possible that printf() would allocate an
additional buffer.
There is also fgets() in the middle which could also do the same.

Looking at get_smaps_bits.c - it seems that the code is ~5 years old :)
I think Mike's patch workarounds the problem for a while, but probably
a better patch
would change (start == where) to ((start <= where) && (where < end)).
Other tests seem to be unaffected as they mlock()/madvise() with a
different PROT_*/MAP*
preventing vma_merge().

-- 
             Dmitry


More information about the CRIU mailing list