This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]