[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