tst-pkey: fix detection of CPU support

  The current tst-pkey.c checks for CPU support using the pkey_alloc
function/syscall and test for EINVAL. In practice ENOSPC can also be
returned. Looking at the kernel code it seems to happen for
architectures which have activated the syscall, but do not have kernel
support yet. This is consistent with the Linux Programmer's Manual,
which says that ENOSPC can be returned "if the processor or operating
system does not support protection keys".

This patch simply tests for EINVAL in addition to ENOSPC. This fixes
misc/tst-pkey on mipsel-linux-gnu.

Changelog:
	* sysdeps/unix/sysv/linux/tst-pkey.c (do_test): Test for CPU support
	using ENOSPC in addition to EINVAL.
---
 ChangeLog                          | 5 +++++
 sysdeps/unix/sysv/linux/tst-pkey.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)
  

On 03/01/2018 14:03, Aurelien Jarno wrote:
> The current tst-pkey.c checks for CPU support using the pkey_alloc
> function/syscall and test for EINVAL. In practice ENOSPC can also be
> returned. Looking at the kernel code it seems to happen for
> architectures which have activated the syscall, but do not have kernel
> support yet. This is consistent with the Linux Programmer's Manual,
> which says that ENOSPC can be returned "if the processor or operating
> system does not support protection keys".
> 
> This patch simply tests for EINVAL in addition to ENOSPC. This fixes
> misc/tst-pkey on mipsel-linux-gnu.

This seems inconsistent of what manual describes as ENOSPC returned code
for pkey_alloc:

3264 @deftypefun int pkey_alloc (unsigned int @var{flags}, unsigned int @var{restrictions})
3265 @standards{Linux, sys/mman.h}
[...]
3274 
3275 The following @code{errno} error conditions are defined for this
3276 function:
3277 
[...]
3289 
3290 @item ENOSPC
3291 All available protection keys already have been allocated.
3292 @end table
3293 @end deftypefun

So it looks the case where kernel is returning ENOSPC for two different 
possible issues and although the program can handle both as a failure to use
pkey, ENOSPC gives the idea that the issues is transitory (a pkey_alloc
might succeed in the future if the resources are available). I think this
inconsistency need to be fixed on kernel.


> 
> Changelog:
> 	* sysdeps/unix/sysv/linux/tst-pkey.c (do_test): Test for CPU support
> 	using ENOSPC in addition to EINVAL.
> ---
>  ChangeLog                          | 5 +++++
>  sysdeps/unix/sysv/linux/tst-pkey.c | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/ChangeLog b/ChangeLog
> index 68b8c93ccc..c5f6f273b0 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2018-01-03  Aurelien Jarno <aurelien@aurel32.net>
> +
> +	* sysdeps/unix/sysv/linux/tst-pkey.c (do_test): Test for CPU support
> +	using ENOSPC in addition to EINVAL.
> +
>  2018-01-02  Wilco Dijkstra  <wdijkstr@arm.com>
>  
>  	* math/math.h (math_errhandling): Set to 0 with __FAST_MATH__.
> diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
> index 5f721d4444..4204e1c3a3 100644
> --- a/sysdeps/unix/sysv/linux/tst-pkey.c
> +++ b/sysdeps/unix/sysv/linux/tst-pkey.c
> @@ -194,7 +194,7 @@ do_test (void)
>        if (errno == ENOSYS)
>          FAIL_UNSUPPORTED
>            ("kernel does not support memory protection keys");
> -      if (errno == EINVAL)
> +      if (errno == EINVAL || errno == ENOSPC)
>          FAIL_UNSUPPORTED
>            ("CPU does not support memory protection keys: %m");
>        FAIL_EXIT1 ("pkey_alloc: %m");
>