[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