[PATCH] Fix tst-pkey.c pkey_alloc return checks and manual

Lucas A. M. Magalhaes lamm@linux.ibm.com
Thu Jan 16 14:51:00 GMT 2020


Quoting Gabriel F. T. Gomes (2020-01-16 10:57:53)
> Hi, Lucas,
> 
> Thanks for doing this.  This failure has haunted my Debian systems for
> a long time.
> 
> The patch looks good to me.  I only have a cosmetic suggestion.
> 
> Reviewed-by: Gabriel F. T. Gomes <gabriel@inconstante.net.br>
> 
> On Thu, 16 Jan 2020, Lucas A. M. Magalhaes wrote:
> 
> > This test was failing in some powerpc systems as it was not checking
> > for ENOSPC return.
> > 
> > As said on the Linux man-pages and can be observed by the implementation
> > at mm/mprotect.c in the Linux Kernel source.  The syscall pkey_alloc can
> > return EINVAL or ENOSPC.  ENOSPC will indicate either that all keys are
> > in use or that the kernel does not support pkeys.
> 
> Good commit message.
> 
> > --- a/manual/memory.texi
> > +++ b/manual/memory.texi
> > @@ -3288,6 +3288,10 @@ in which memory protection keys are disabled.
> >  
> >  @item ENOSPC
> >  All available protection keys already have been allocated.
> > +
> > +The system does not implement memory protection keys or runs in a mode
> > +in which memory protection keys are disabled.
> > +
> 
> I think the wording at the commit message is better, because it makes
> it clear that it's one situation or the other, so maybe:
> 
>   Either all available protection keys already have been allocated, or
>   the system does not implement memory protection keys, or runs in a
>   mode in which memory protection keys are disabled.

Thanks Gabriel,

I actually agree with you, but I'm folowing the pattern of the EINVAL
explanation.  So I prefere leaving as it is. Maybe, in a furure patch,
change both return explanations in the way you suggest.



More information about the Libc-alpha mailing list