[PATCH v2 0/6] powerpc/pkeys: fixes to pkeys

[Ram Pai]

On Sun, Jun 24, 2018 at 01:02:50AM +1000, Michael Ellerman wrote:
> Ram Pai <linuxram at us.ibm.com> writes:
> > On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote:
> >> Florian Weimer <fweimer at redhat.com> writes:
> >> > On 06/19/2018 02:40 PM, Michael Ellerman wrote:
> >> >>> I tested the whole series with the new selftests, with the printamr.c
> >> >>> program I posted earlier, and the glibc test for pkey_alloc &c.  The
> >> >>> latter required some test fixes, but now passes as well.  As far as I
> >> >>> can tell, everything looks good now.
> >> >>>
> >> >>> Tested-By: Florian Weimer<fweimer at redhat.com>
> >> >> Thanks. I'll add that to each patch I guess, if you're happy with that?
> >> >
> >> > Sure, but I only tested the whole series as a whole.
> >> 
> >> Yeah OK. We don't have a good way to express that, other than using a
> >> merge which I'd prefer to avoid.
> >> 
> >> So I've tagged them all with your Tested-by. If any of them turn out to
> >> have bugs you can blame me :)
> >
> > I just tested the patches incrementally using the pkey selftests.
> >
> > So I feel confident these patches are not bugs. I will take the blame
> > if the blame lands on Mpe  :)
> 
> Did you run core-pkey and ptrace-pkey?
> 
> The pkey selftests that are in tools/testing/selftests/powerpc/ptrace ?

No. Ran the tools/testing/selftests/vm/protection_keys.

> 
> Because those are failing for me:
> 
>   test: core_pkey
>   tags: git_version:c899d94
>   [FAIL] Test FAILED on line 245
>   [Core Read (Running)]          AMR: 3fcfffffffffffff IAMR: 1105555555555555 UAMOR: 33cfffffffffffff
>   failure: core_pkey
>   
>   test: ptrace_pkey
>   tags: git_version:c899d94
>   [FAIL] Test FAILED on line 214
>   [Ptrace Read (Running)]        AMR: 3fcfffffffffffff IAMR: 1105555555555555 UAMOR: 33cfffffffffffff
>   [User Write (Running)]         AMR: 3fffffffffffffff pkey1: 3 pkey2: 4 pkey3: 5
>   failure: ptrace_pkey
> 
> 
> Some of which is presumably test case bugs.

The test case is assuming execute-disable is disabled by default, i.e
all keys by default are execute-enabled.  The new behavior by default is
execute-disable.

The test case need to be made aware of that.



> but there's at least one
> kernel bug with the UAMOR handling.

hmm.. yes. The UAMOR of the key is getting reset when the key is freed.
An artifact of the old behavior. The new behavior should never touch the
UAMOR register after initialization.

will send fixes to the above two anomolies.
RP