[CRIU] zdtm thp_disable test fails on VZ7

[Mike Rapoport]

On Fri, Feb 08, 2019 at 01:27:43AM +0000, Dmitry Safonov wrote:
> +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.

MADV_DONTFORK, MADV_WIPEONFORK, MADV_MERGEABLE (if CONFIG_KSM=y), maybe
some others.
We don't really care here about the VMA behaviour, we just need it to have
some of "nonstandard" flags set.
It won't prevent vma_merge in 100%, but I chances some glibc internal
mmap() would use some of those for adjacent VMA are negligible.
 
> 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().

we can even use PROT_NONE here, as we don't need to read/write the memory.
 
> -- 
>              Dmitry
> 

-- 
Sincerely yours,
Mike.