[PATCH] Fix tst-pkey expectations on pkey_get

[PATCH] Fix tst-pkey expectations on pkey_get

[Lucas A. M. Magalhaes]

From the GNU LibC Manual the pkey_set can receive a combination of
PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.

The test expects that after setting
(PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
describe the state of the key in this case.

---
Hi,

Florian, Your patch including pkey_set and pkey_get looks good to me.
Can you merge it?  This one
https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html.

With this there will be one failure on this test on powerpc machines.
The test expects that during a signal handling the pkey_get returns
PKEY_DISABLE_ACCESS for all keys. In my tests it returns the same
permissions as before the signal. I couldn't find where this is done for
x86. Is this kernel implementation?

 sysdeps/unix/sysv/linux/tst-pkey.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
index 4ea1bc4f9a..11084520b3 100644
--- a/sysdeps/unix/sysv/linux/tst-pkey.c
+++ b/sysdeps/unix/sysv/linux/tst-pkey.c
@@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
 
 /* The keys used for testing.  These have been allocated with access
    rights set based on their array index.  */
-enum { key_count = 4 };
+enum { key_count = 3 };
 static int keys[key_count];
 static volatile int *pages[key_count];
 
-- 
2.20.1

Re: [PATCH] Fix tst-pkey expectations on pkey_get

[Florian Weimer]

* Lucas A. M. Magalhaes:

> Florian, Your patch including pkey_set and pkey_get looks good to me.
> Can you merge it?  This one
> https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html.

Thanks.  Is the patch really correct for 32-bit userspace?

> With this there will be one failure on this test on powerpc machines.
> The test expects that during a signal handling the pkey_get returns
> PKEY_DISABLE_ACCESS for all keys. In my tests it returns the same
> permissions as before the signal. I couldn't find where this is done for
> x86. Is this kernel implementation?

POWER has read-disable and write-disable flags which work independently.
The kernel-defined flags cannot represent the read-disable
configuration.  At the time, there was no read-disable flag allocated in
the kernel.  Has this changed?  (See the ”Translate” comments in my
patch.)

On x86, the hardware has write-disable and read-write-disable flags
instead, which matches the original UAPI interfaces.  This is why no
translation is necessary.

Thanks,
Florian

Re: [PATCH] Fix tst-pkey expectations on pkey_get

[Lucas A. M. Magalhaes]

Quoting Florian Weimer (2020-02-07 15:22:16)
> * Lucas A. M. Magalhaes:
> 
> > Florian, Your patch including pkey_set and pkey_get looks good to me.
> > Can you merge it?  This one
> > https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html.
> 
> Thanks.  Is the patch really correct for 32-bit userspace?
> 

Thanks for pointing it out. Even in 32-bit mode the mtspr will effect all
64 bits and there is no 32 bit limitation for AMR. I will try to setup
a 32 bit userspace machine with pkeys enabled to test this out.

> > With this there will be one failure on this test on powerpc machines.
> > The test expects that during a signal handling the pkey_get returns
> > PKEY_DISABLE_ACCESS for all keys. In my tests it returns the same
> > permissions as before the signal. I couldn't find where this is done for
> > x86. Is this kernel implementation?
> 
> POWER has read-disable and write-disable flags which work independently.
> The kernel-defined flags cannot represent the read-disable
> configuration.  At the time, there was no read-disable flag allocated in
> the kernel.  Has this changed?  (See the ”Translate” comments in my
> patch.)
> 

I think we are talking about this patch
https://marc.info/?l=linux-api&m=154390462121345&w=2 that you were
discussing a PKEY_DISABLE_READ flag for pkey_alloc. Unfortunately It
was not merged.

I agree that this work should be done. But this should not block the
pkey_get and pkey_set implementation for power to be merged for the
actual api.

> On x86, the hardware has write-disable and read-write-disable flags
> instead, which matches the original UAPI interfaces.  This is why no
> translation is necessary.

Excuse my ignorance. How this translation problem influences the signal
handling behaviour?

Re: [PATCH] Fix tst-pkey expectations on pkey_get

[Florian Weimer]

* Lucas A. M. Magalhaes:

> Quoting Florian Weimer (2020-02-07 15:22:16)
>> * Lucas A. M. Magalhaes:
>> 
>> > Florian, Your patch including pkey_set and pkey_get looks good to me.
>> > Can you merge it?  This one
>> > https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html.
>> 
>> Thanks.  Is the patch really correct for 32-bit userspace?
>> 
>
> Thanks for pointing it out. Even in 32-bit mode the mtspr will effect all
> 64 bits and there is no 32 bit limitation for AMR. I will try to setup
> a 32 bit userspace machine with pkeys enabled to test this out.

Thanks.  We may have to tweak the constraints a little bit, though.

>> > With this there will be one failure on this test on powerpc machines.
>> > The test expects that during a signal handling the pkey_get returns
>> > PKEY_DISABLE_ACCESS for all keys. In my tests it returns the same
>> > permissions as before the signal. I couldn't find where this is done for
>> > x86. Is this kernel implementation?
>> 
>> POWER has read-disable and write-disable flags which work independently.
>> The kernel-defined flags cannot represent the read-disable
>> configuration.  At the time, there was no read-disable flag allocated in
>> the kernel.  Has this changed?  (See the ”Translate” comments in my
>> patch.)
>> 
>
> I think we are talking about this patch
> https://marc.info/?l=linux-api&m=154390462121345&w=2 that you were
> discussing a PKEY_DISABLE_READ flag for pkey_alloc. Unfortunately It
> was not merged.

Right.

> I agree that this work should be done. But this should not block the
> pkey_get and pkey_set implementation for power to be merged for the
> actual api.

That sounds about right.

>> On x86, the hardware has write-disable and read-write-disable flags
>> instead, which matches the original UAPI interfaces.  This is why no
>> translation is necessary.
>
> Excuse my ignorance. How this translation problem influences the signal
> handling behaviour?

The signal handling behavior is just different.  If I recall correctly,
x86 always resets PKRU to a mostly-disable value, while POWER inherits
the AMR value from the interrupted thread.  The POWER behavior seems
more useful to me, but that depends on what the programmer tries to do.

I think I have posted x86 patches for changing the behavior, too.

Thanks,
Florian

Re: [PATCH] Fix tst-pkey expectations on pkey_get

[Lucas A. M. Magalhaes]

> >> Thanks.  Is the patch really correct for 32-bit userspace?
> >> 
> >
> > Thanks for pointing it out. Even in 32-bit mode the mtspr will effect all
> > 64 bits and there is no 32 bit limitation for AMR. I will try to setup
> > a 32 bit userspace machine with pkeys enabled to test this out.
> 
> Thanks.  We may have to tweak the constraints a little bit, though.
> 

Actually there is a problem in this regard we may encounter.  We cannot
ensure that in a context change the upper bits of the GPR will remain
the same. We could either

1. Restrict the usage of the upper pkeys on 32bits.  Maybe the kernel
already restrict already on pkey_alloc.

2. Make it ppc64 specific.

> >> On x86, the hardware has write-disable and read-write-disable flags
> >> instead, which matches the original UAPI interfaces.  This is why no
> >> translation is necessary.
> >
> > Excuse my ignorance. How this translation problem influences the signal
> > handling behaviour?
> 
> The signal handling behavior is just different.  If I recall correctly,
> x86 always resets PKRU to a mostly-disable value, while POWER inherits
> the AMR value from the interrupted thread.  The POWER behavior seems
> more useful to me, but that depends on what the programmer tries to do.
> 

What do you suggest for this.  To change x86 behavior or too change the
test to accept both behaviors?

> I think I have posted x86 patches for changing the behavior, too.
> 

I could not find it.

Re: [PATCH] Fix tst-pkey expectations on pkey_get

[Florian Weimer]

* Lucas A. M. Magalhaes:

>> >> Thanks.  Is the patch really correct for 32-bit userspace?
>> >> 
>> >
>> > Thanks for pointing it out. Even in 32-bit mode the mtspr will effect all
>> > 64 bits and there is no 32 bit limitation for AMR. I will try to setup
>> > a 32 bit userspace machine with pkeys enabled to test this out.
>> 
>> Thanks.  We may have to tweak the constraints a little bit, though.
>> 
>
> Actually there is a problem in this regard we may encounter.  We cannot
> ensure that in a context change the upper bits of the GPR will remain
> the same. We could either
>
> 1. Restrict the usage of the upper pkeys on 32bits.  Maybe the kernel
> already restrict already on pkey_alloc.
>
> 2. Make it ppc64 specific.

Option 2 is fine with me.

>> >> On x86, the hardware has write-disable and read-write-disable flags
>> >> instead, which matches the original UAPI interfaces.  This is why no
>> >> translation is necessary.
>> >
>> > Excuse my ignorance. How this translation problem influences the signal
>> > handling behaviour?
>> 
>> The signal handling behavior is just different.  If I recall correctly,
>> x86 always resets PKRU to a mostly-disable value, while POWER inherits
>> the AMR value from the interrupted thread.  The POWER behavior seems
>> more useful to me, but that depends on what the programmer tries to do.
>> 
>
> What do you suggest for this.  To change x86 behavior or too change the
> test to accept both behaviors?

For now: Change the test to accept both behaviors.

>> I think I have posted x86 patches for changing the behavior, too.
>> 
>
> I could not find it.

It was a kernel patch:

  <https://marc.info/?l=linux-mm&m=152526767625176>
  <https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-May/172420.html>

Thanks,
Florian

[PATCH V2] Fix tst-pkey expectations on pkey_get

[Lucas A. M. Magalhaes]

From the GNU LibC Manual the pkey_set can receive a combination of
PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.

The test expects that after setting
(PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
describe the state of the key in this case.

The pkey behavior during signal handling is different between x86 and
POWER.  This change make the test compatible with both architectures.

---

Hi,

This test still needs the patch on the link to work on POWER.
https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html

in V2:
	- Fix signal handling expectations to accept x86 and POWER behavior.

 sysdeps/unix/sysv/linux/tst-pkey.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
index 4ea1bc4f9a..ffa65cd5de 100644
--- a/sysdeps/unix/sysv/linux/tst-pkey.c
+++ b/sysdeps/unix/sysv/linux/tst-pkey.c
@@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
 
 /* The keys used for testing.  These have been allocated with access
    rights set based on their array index.  */
-enum { key_count = 4 };
+enum { key_count = 3 };
 static int keys[key_count];
 static volatile int *pages[key_count];
 
@@ -118,7 +118,8 @@ sigusr1_handler (int signum)
 {
   TEST_COMPARE (signum, SIGUSR1);
   for (int i = 0; i < key_count; ++i)
-    TEST_COMPARE (pkey_get (keys[i]), PKEY_DISABLE_ACCESS);
+    TEST_VERIFY (pkey_get (keys[i]) == PKEY_DISABLE_ACCESS
+                 || pkey_get (keys[i]) == i);
   sigusr1_handler_ran = 1;
 }
 
-- 
2.20.1

Re: [PATCH V2] Fix tst-pkey expectations on pkey_get

[Florian Weimer]

* Lucas A. M. Magalhaes:

> From the GNU LibC Manual the pkey_set can receive a combination of
> PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
> is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.

“glibc manual” or “GNU C Library manual”.

> The test expects that after setting
> (PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
> same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
> describe the state of the key in this case.

Please reference [BZ #23202] in the commit message.

> The pkey behavior during signal handling is different between x86 and
> POWER.  This change make the test compatible with both architectures.

> diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
> index 4ea1bc4f9a..ffa65cd5de 100644
> --- a/sysdeps/unix/sysv/linux/tst-pkey.c
> +++ b/sysdeps/unix/sysv/linux/tst-pkey.c
> @@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
>  
>  /* The keys used for testing.  These have been allocated with access
>     rights set based on their array index.  */
> -enum { key_count = 4 };
> +enum { key_count = 3 };
>  static int keys[key_count];
>  static volatile int *pages[key_count];

Okay.

> @@ -118,7 +118,8 @@ sigusr1_handler (int signum)
>  {
>    TEST_COMPARE (signum, SIGUSR1);
>    for (int i = 0; i < key_count; ++i)
> -    TEST_COMPARE (pkey_get (keys[i]), PKEY_DISABLE_ACCESS);
> +    TEST_VERIFY (pkey_get (keys[i]) == PKEY_DISABLE_ACCESS
> +                 || pkey_get (keys[i]) == i);
>    sigusr1_handler_ran = 1;
>  }

Please add a comment explicitly describing the POWER and x86-64
behaviors.  Thanks.

Florian

[PATCH v3] Fix tst-pkey expectations on pkey_get [BZ #23202]

[Lucas A. M. Magalhaes]

From the GNU C Library manual the pkey_set can receive a combination of
PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.

The test expects that after setting
(PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
describe the state of the key in this case.

The pkey behavior during signal handling is different between x86 and
POWER.  This change make the test compatible with both architectures.

---

Hi,

This test still needs the patch on the link to work on POWER.
https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html

in V3:
	- Commit message changes.
	- Add comments.

in V2:
	- Fix signal handling expectations to accept x86 and POWER behavior.

 sysdeps/unix/sysv/linux/tst-pkey.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
index 4ea1bc4f9a..34a4d890b5 100644
--- a/sysdeps/unix/sysv/linux/tst-pkey.c
+++ b/sysdeps/unix/sysv/linux/tst-pkey.c
@@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
 
 /* The keys used for testing.  These have been allocated with access
    rights set based on their array index.  */
-enum { key_count = 4 };
+enum { key_count = 3 };
 static int keys[key_count];
 static volatile int *pages[key_count];
 
@@ -111,14 +111,16 @@ check_page_access (int page, bool write)
 }
 
 static volatile sig_atomic_t sigusr1_handler_ran;
-
-/* Used to check that access is revoked in signal handlers.  */
+/* Used to check the behavior in signal handlers.  In x86 all access are
+revoked during signal handling.  Otherwise in PowerPC the key will hold it's
+permissions. This test accepts both approaches.  */
 static void
 sigusr1_handler (int signum)
 {
   TEST_COMPARE (signum, SIGUSR1);
   for (int i = 0; i < key_count; ++i)
-    TEST_COMPARE (pkey_get (keys[i]), PKEY_DISABLE_ACCESS);
+    TEST_VERIFY (pkey_get (keys[i]) == PKEY_DISABLE_ACCESS
+                 || pkey_get (keys[i]) == i);
   sigusr1_handler_ran = 1;
 }
 
-- 
2.20.1

Re: [PATCH v3] Fix tst-pkey expectations on pkey_get [BZ #23202]

[Florian Weimer]

* Lucas A. M. Magalhaes:

> -/* Used to check that access is revoked in signal handlers.  */
> +/* Used to check the behavior in signal handlers.  In x86 all access are
> +revoked during signal handling.  Otherwise in PowerPC the key will hold it's
> +permissions. This test accepts both approaches.  */

Please indent the comment as usual.  I think on POWER, the permissions
are inherited by the interrupted thread (there are no default
permissions for signal handlers).

Thanks,
Florian

[PATCH v4] Fix tst-pkey expectations on pkey_get [BZ #23202]

[Lucas A. M. Magalhaes]

From the GNU C Library manual the pkey_set can receive a combination of
PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.

The test expects that after setting
(PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
describe the state of the key in this case.

The pkey behavior during signal handling is different between x86 and
POWER.  This change make the test compatible with both architectures.

---

Hi,

in V4:
	- Fix comments.

in V3:
	- Commit message changes.
	- Add comments.

in V2:
	- Fix signal handling expectations to accept x86 and POWER behavior.

 sysdeps/unix/sysv/linux/tst-pkey.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
index 4ea1bc4f9a..cba40c73de 100644
--- a/sysdeps/unix/sysv/linux/tst-pkey.c
+++ b/sysdeps/unix/sysv/linux/tst-pkey.c
@@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
 
 /* The keys used for testing.  These have been allocated with access
    rights set based on their array index.  */
-enum { key_count = 4 };
+enum { key_count = 3 };
 static int keys[key_count];
 static volatile int *pages[key_count];
 
@@ -111,14 +111,16 @@ check_page_access (int page, bool write)
 }
 
 static volatile sig_atomic_t sigusr1_handler_ran;
-
-/* Used to check that access is revoked in signal handlers.  */
+/* Used to check the behavior in signal handlers.  In x86 all access are
+   revoked during signal handling.  In PowerPC the key permissions are
+   inherited by the interrupted thread. This test accept both approaches.  */
 static void
 sigusr1_handler (int signum)
 {
   TEST_COMPARE (signum, SIGUSR1);
   for (int i = 0; i < key_count; ++i)
-    TEST_COMPARE (pkey_get (keys[i]), PKEY_DISABLE_ACCESS);
+    TEST_VERIFY (pkey_get (keys[i]) == PKEY_DISABLE_ACCESS
+                 || pkey_get (keys[i]) == i);
   sigusr1_handler_ran = 1;
 }
 
-- 
2.20.1

Re: [PATCH v4] Fix tst-pkey expectations on pkey_get [BZ #23202]

[Florian Weimer]

* Lucas A. M. Magalhaes:

> diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c
> index 4ea1bc4f9a..cba40c73de 100644
> --- a/sysdeps/unix/sysv/linux/tst-pkey.c
> +++ b/sysdeps/unix/sysv/linux/tst-pkey.c
> @@ -37,7 +37,7 @@ static pthread_barrier_t barrier;
>  
>  /* The keys used for testing.  These have been allocated with access
>     rights set based on their array index.  */
> -enum { key_count = 4 };
> +enum { key_count = 3 };
>  static int keys[key_count];
>  static volatile int *pages[key_count];
>  
> @@ -111,14 +111,16 @@ check_page_access (int page, bool write)
>  }
>  
>  static volatile sig_atomic_t sigusr1_handler_ran;
> -
> -/* Used to check that access is revoked in signal handlers.  */
> +/* Used to check the behavior in signal handlers.  In x86 all access are
> +   revoked during signal handling.  In PowerPC the key permissions are
> +   inherited by the interrupted thread. This test accept both approaches.  */
>  static void
>  sigusr1_handler (int signum)
>  {
>    TEST_COMPARE (signum, SIGUSR1);
>    for (int i = 0; i < key_count; ++i)
> -    TEST_COMPARE (pkey_get (keys[i]), PKEY_DISABLE_ACCESS);
> +    TEST_VERIFY (pkey_get (keys[i]) == PKEY_DISABLE_ACCESS
> +                 || pkey_get (keys[i]) == i);
>    sigusr1_handler_ran = 1;
>  }

This version looks okay to me.  Thanks.

Florian

Re: [PATCH v4] Fix tst-pkey expectations on pkey_get [BZ #23202]

[Tulio Magno Quites Machado Filho]

"Lucas A. M. Magalhaes" <lamm@linux.ibm.com> writes:

> From the GNU C Library manual the pkey_set can receive a combination of
> PKEY_DISABLE_WRITE and PKEY_DISABLE_ACCESS.  However PKEY_DISABLE_ACCESS
> is more restrictive than PKEY_DISABLE_WRITE and includes its behavior.
>
> The test expects that after setting
> (PKEY_DISABLE_WRITE|PKEY_DISABLE_ACCESS) pkey_get should return the
> same.  This may not be true as PKEY_DISABLE_ACCESS will succeed in
> describe the state of the key in this case.
>
> The pkey behavior during signal handling is different between x86 and
> POWER.  This change make the test compatible with both architectures.

The patch LGTM.
This test is now passing on Linux >= 5.0, but it still fails on Linux <= 4.18
because of issues in the kernel.
I'm not sure if 4.19 should work.

Old kernels do return valid data:

[pid 56757] pkey_alloc(0, 0 <unfinished ...>
[pid 56758] set_robust_list(0x7fff8994f260, 24 <unfinished ...>
[pid 56757] <... pkey_alloc resumed> )  = 2
[pid 56758] <... set_robust_list resumed> ) = 0
[pid 56757] pkey_alloc(0, PKEY_DISABLE_ACCESS <unfinished ...>
[pid 56758] futex(0x100208a4, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 56757] <... pkey_alloc resumed> )  = 3
[pid 56757] pkey_alloc(0, PKEY_DISABLE_WRITE) = 4
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89130000
[pid 56757] pkey_mprotect(0x7fff89130000, 65536, PROT_READ|PROT_WRITE, 2) = 0
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89120000
[pid 56757] pkey_mprotect(0x7fff89120000, 65536, PROT_READ|PROT_WRITE, 3) = 0
[pid 56757] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fff89110000
[pid 56757] pkey_mprotect(0x7fff89110000, 65536, PROT_READ|PROT_WRITE, 4) = 0
[pid 56757] futex(0x100208a4, FUTEX_WAKE_PRIVATE, 2147483647) = 1
[pid 56758] <... futex resumed> )       = 0
[pid 56757] futex(0x7fff8994f250, FUTEX_WAIT, 56758, NULL <unfinished ...>
[pid 56758] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fff81110000
[pid 56758] munmap(0x7fff81110000, 49217536) = 0
[pid 56758] munmap(0x7fff88000000, 17891328) = 0
[pid 56758] mprotect(0x7fff84000000, 196608, PROT_READ|PROT_WRITE) = 0
[pid 56758] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 56758] rt_sigaction(SIGSEGV, {sa_handler=0x1001fca8, sa_mask=[], sa_flags=SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0
[pid 56758] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[SEGV], sa_flags=SA_RESTART}, {sa_handler=0x1001fca8, sa_mask=[], sa_flags=SA_RESETHAND|SA_SIGINFO}, 8) = 0
[pid 56758] write(1, "error: ../sysdeps/unix/sysv/linu"..., 90error: ../sysdeps/unix/sysv/linux/tst-pkey.c:161: not true: !check_page_access (i, false)
) = 90

Anyway, pushed as 8d42bf859a289944749d9f978c076cd318119867.

Thanks!

-- 
Tulio Magno