[CRIU] [PATCH v2] rework criu check logic

[Filipe Brandenburger]

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
> Error (cr-check.c:629): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP
> Error (cr-check.c:673): Dumping seccomp filters not supported: Input/output
> error
> Error (timerfd.c:55): timerfd: No timerfd support for c/r: Inappropriate
> ioctl for device
> Error (cr-check.c:307): fdinfo doesn't contain the mnt_id field
> Warn  (cr-check.c:773): Skipping unsupported AIO remap
> Warn  (cr-check.c:789): fdinfo doesn't contain the lock field
> Warn  (cr-check.c:827): Skipping cgroup namespaces check
> $ 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