[CRIU] [PATCH v2] rework criu check logic

[Pavel Emelyanov]

On 03/15/2016 02:33 AM, Filipe Brandenburger wrote:
> Hi,
> 
> On Mon, Mar 14, 2016 at 4:14 PM, Saied Kazemi <saied at google.com> wrote:
>> Yes, there's definitely a bug.  Filipe was suggesting that perhaps the
>> prctl() calls are failing not due to lack of support in the kernel but due
>> to some other error (e.g., passing wrong parameters).
> 
> Yes. In fact Pavel included this change of brk -> sbrk which fixes
> this issue on that specific line that was failing for us...
> 
>> This causes "criu check" to think the old API is not supported but in reality
>> it is and that's why c/r works.
>>
>> Below  is a complete log showing all your patches applied.  Hope this helps!
> 
>> $ sudo ./criu/criu check --ms
>> Warn  (cr-check.c:195): Skipping unssuported PR_SET_MM_MAP

Here it is -- the prctl checks all pass :) The warning here should not be a
warning, I would say, it just says, that we don't care that SET_MM_MAP doesn't
work and go ahead to check for older prctls.

>> Error (cr-check.c:629): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP

This is seccomp suspend API that should go to category 2 (optional)

>> Error (cr-check.c:673): Dumping seccomp filters not supported: Input/output
>> error

Same here

>> Error (timerfd.c:55): timerfd: No timerfd support for c/r: Inappropriate
>> ioctl for device

And here

>> Error (cr-check.c:307): fdinfo doesn't contain the mnt_id field

And actually here, though todays containers _typicaly_ create more than one mntns :(
However, this doesn't block C/R of simple ones, so I'd still put this into category 2.

>> Warn  (cr-check.c:773): Skipping unsupported AIO remap

Same here

>> Warn  (cr-check.c:789): fdinfo doesn't contain the lock field

Ditto

>> Warn  (cr-check.c:827): Skipping cgroup namespaces check

And that's it.

So, from what I see your previous patch that splits all the checks into two cats,
plus Filipe's fix (merged) plus my fix for brk/sbrk plus keeping all the prctls
checks in category 1 should make us good criu check action.

>> $ echo $?
>> 1
> 
> I see the same here, unsurprisingly since both Saied and I are testing
> the same Ubuntu Trusty based on 3.13 kernel.
> 
> I haven't gone back to the code to see which of those "Error"s
> (ptrace/seccomp, seccomp filters, timerfd, mnt_id field) is causing
> "criu check --ms" to fail, even though C/R seems to work alright on
> this O.S... Shouldn't be too hard to trace it down.
> 
> Cheers,
> Filipe
> .
>