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

[Dmitry Safonov]

Drop this version - I'll resend it on the top of Pasha's
"Speed up kdat checks" patches set :)

Also, this thing should be removed and included proper syscall-header.
Seems like, I copy-pasted it from my kernel sefltest patch and forgot
to correct:
> #ifndef __NR32_mmap2
> # define __NR32_mmap2 192
> #endif
Will do in v2.

2017-04-22 12:01 GMT+03:00 Dmitry Safonov <0x7f454c46 at gmail.com>:
> 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