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

On Sun, Jun 24, 2018 at 01:02:50AM +1000, Michael Ellerman wrote:

Ram Pai [off-list ref] writes:

quoted

On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote:

quoted

Florian Weimer [off-list ref] writes:

quoted

On 06/19/2018 02:40 PM, Michael Ellerman wrote:

quoted

quoted

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<redacted>

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