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 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.
--
Joseph S. Myers
joseph@codesourcery.com