This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: Implement interfaces for memory protection keys
On 06/11/2017 20:59, Joseph Myers wrote:
> On Mon, 6 Nov 2017, Florian Weimer wrote:
>
>>>> diff --git a/sysdeps/unix/sysv/linux/syscalls.list
>>>> b/sysdeps/unix/sysv/linux/syscalls.list
>>>> index 40c4fbb9ea..6f657eea2e 100644
>>>> --- a/sysdeps/unix/sysv/linux/syscalls.list
>>>> +++ b/sysdeps/unix/sysv/linux/syscalls.list
>>>> @@ -110,3 +110,6 @@ setns EXTRA setns i:ii setns
>>>> process_vm_readv EXTRA process_vm_readv i:ipipii process_vm_readv
>>>> process_vm_writev EXTRA process_vm_writev i:ipipii process_vm_writev
>>>> memfd_create EXTRA memfd_create i:si memfd_create
>>>> +pkey_alloc EXTRA pkey_alloc i:ii pkey_alloc
>>>> +pkey_free EXTRA pkey_free i:i pkey_free
>>>> +pkey_mprotect EXTRA pkey_mprotect i:aiii pkey_mprotect
>>>
>>> I do not think we can them as default since build against kernel headers
>>> older than v4.9 won't have __NR_pkey_{alloc,free,mprotect). We need
>>> default implementation with #ifdef __NR_....
>>
>> Hmm. I checked that we'd fall back to an ENOSYS stub, but this was for
>> memfd_create, which had the stub in the generic API. That won't apply here,
>> so I will have to rework this a bit.
>
> I'd expect the stub-syscalls code in sysdeps/unix/Makefile to apply here.
> These entries are essentially much like the bdflush one, which exercises
> the ENOSYS generation on x86_64 as a syscall not existing there.
>
Indeed this is what happens for non defined __NR_ syscalls, sorry for the trouble.