[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?