This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix tst-pkey.c pkey_alloc return checks and manual
- From: "Gabriel F. T. Gomes" <gabriel at inconstante dot net dot br>
- To: "Lucas A. M. Magalhaes" <lamm at linux dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>, <tuliom at linux dot ibm dot com>
- Date: Thu, 16 Jan 2020 10:57:53 -0300
- Subject: Re: [PATCH] Fix tst-pkey.c pkey_alloc return checks and manual
- References: <20200116133912.2578-1-lamm@linux.ibm.com>
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.