[CRIU] [PATCH 3/3] ia32/kdat: Check for 32-bit mmap() bug

[Dmitry Safonov]

2017-04-22 2:42 GMT+03:00 Andrei Vagin <avagin at virtuozzo.com>:
> On Fri, Apr 21, 2017 at 11:28:12PM +0300, Dmitry Safonov wrote:
>> There were kernel bug with 32-bit mmap() returning 64-bit pointer.
>> The fix is in linux-next, will go to v4.12 kernel.
>> Checkpointing after v4.9 kernel works good, but restoring will
>> result in application which will mmap() 64-bit addresses resulting
>> in segfault/memory corruptions/etc.
>> As our policy is fail on dump if we can't restore on the same target,
>> error checkpointing for v4.9.
>
> Was the fix for this kernel issue applied to stable kernels (4.9, 4.10)?

No, they didn't. I hoped they would, but fix for kernel came quite big,
introduced new mmap bases, reworked mmap() logic on x86 - so, it's
not worth for them to apply it to stable (as it needed only by criu ATM
and changes logic alot).

> If the answer is yes, I don't think that we need to add this check.
> Pavel found that we spend a lot of time in kdat code, so we need to
> think how to optimize it instead of adding new thing into it.

Yes, that what also my concern. There is shmemdev test, which
parses /proc/self/maps and in the first version (didn't send) of the
patch I combined two tests to parse maps files only once.
But then, because of this concern, I was reluctant to parse maps
at all (as it'll be slow) - and finally have found the way to check
bug presence by the cost of 2 mmap(), 1 munmap() and fork().
There is a comment in-code about that also.

So, what I think - maybe we rework kdat logic, so it will run
the tests in async, waiting for their ending?
AFAIR, tests are independent for each other.

-- 
             Dmitry