[CRIU] [PATCH 3/3] crtools: no more linked with builtin syscall
Laurent Dufour
ldufour at linux.vnet.ibm.com
Tue Mar 15 03:24:50 PDT 2016
On 14/03/2016 23:56, Andrew Vagin wrote:
> On Wed, Feb 03, 2016 at 05:13:48PM +0100, Laurent Dufour wrote:
>> diff --git a/shmem.c b/shmem.c
>> index b2900f4f875d..0f9da630ccc5 100644
>> --- a/shmem.c
>> +++ b/shmem.c
>> @@ -216,7 +216,7 @@ int get_shmem_fd(int pid, VmaEntry *vi)
>>
>> flags = MAP_SHARED;
>> if (kdat.has_memfd) {
>> - f = sys_memfd_create("", 0);
>> + f = syscall(SYS_memfd_create, "", 0);
>
> SYS_memfd_create is defined in glibc which is updated after the kernel.
>
> Without this patch we could install a new kernel and start to use new
> system calls.
>
> Now we need to wait when these syscalls appear in glibc. We need to
> find a way how to fix this issue.
>
> * It is impossible to test new feature in linux-next kernels
> * We back-port a required syscalls into the OpenVZ kernel (e.g.
> memfd_create), but we don't provide glibc for these kernels.
>
> Can we generate a header file with system-call numbers?
There is already a generated file containing all the needed system call
SYS_* defines : "syscall-codes.h".
Unfortunately the way it is generated is forcing the definition of the
SYS_* even if it is already defined by the C library's header files, so
I can't be included as is.
I'm working on a patch changing the way this file is defined, I'll send
it asap.
Cheers,
Laurent.
More information about the CRIU
mailing list