| Message ID | 1528936144-6696-1-git-send-email-linuxram@us.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | powerpc/pkeys: fixes to pkeys | expand |
On 06/14/2018 02:28 AM, Ram Pai wrote: > Assortment of fixes to pkey. > > Patch 1 makes pkey consumable in multithreaded applications. > > Patch 2 fixes fork behavior to inherit the key attributes. > > Patch 3 A off-by-one bug made one key unusable. Fixes it. > > Patch 4 Execute-only key is preallocated. > > Patch 5 Makes pkey-0 less special. > > Patch 6 Deny by default permissions on all unallocated keys. > > Passes all selftests on powerpc. Also behavior verified to be correct > by Florian. > > Changelog: > > v2: . fixed merge conflict with upstream code. > . Add patch 6. Makes the behavior consistent > with that on x86. (Except signal handling, but I agree with Ram that the POWER behavior is the correct one.) > Ram Pai (6): > powerpc/pkeys: Enable all user-allocatable pkeys at init. > powerpc/pkeys: Save the pkey registers before fork > powerpc/pkeys: fix calculation of total pkeys. > powerpc/pkeys: Preallocate execute-only key > powerpc/pkeys: make protection key 0 less special > powerpc/pkeys: Deny read/write/execute by default 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@redhat.com> Thanks, Florian
Florian Weimer <fweimer@redhat.com> writes: > On 06/14/2018 02:28 AM, Ram Pai wrote: >> Assortment of fixes to pkey. >> >> Patch 1 makes pkey consumable in multithreaded applications. >> >> Patch 2 fixes fork behavior to inherit the key attributes. >> >> Patch 3 A off-by-one bug made one key unusable. Fixes it. >> >> Patch 4 Execute-only key is preallocated. >> >> Patch 5 Makes pkey-0 less special. >> >> Patch 6 Deny by default permissions on all unallocated keys. >> >> Passes all selftests on powerpc. Also behavior verified to be correct >> by Florian. >> >> Changelog: >> >> v2: . fixed merge conflict with upstream code. >> . Add patch 6. Makes the behavior consistent >> with that on x86. > > (Except signal handling, but I agree with Ram that the POWER behavior is > the correct one.) > >> Ram Pai (6): >> powerpc/pkeys: Enable all user-allocatable pkeys at init. >> powerpc/pkeys: Save the pkey registers before fork >> powerpc/pkeys: fix calculation of total pkeys. >> powerpc/pkeys: Preallocate execute-only key >> powerpc/pkeys: make protection key 0 less special >> powerpc/pkeys: Deny read/write/execute by default > > 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@redhat.com> Thanks. I'll add that to each patch I guess, if you're happy with that? cheers
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@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. Thanks, Florian
Florian Weimer <fweimer@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@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 :) cheers
On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote: > Florian Weimer <fweimer@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@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 :) RP
Ram Pai <linuxram@us.ibm.com> writes: > On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote: >> Florian Weimer <fweimer@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@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 ? 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, but there's at least one kernel bug with the UAMOR handling. So this series will have to wait until next week :/ cheers
On Sun, Jun 24, 2018 at 01:02:50AM +1000, Michael Ellerman wrote: > Ram Pai <linuxram@us.ibm.com> writes: > > On Thu, Jun 21, 2018 at 08:28:47PM +1000, Michael Ellerman wrote: > >> Florian Weimer <fweimer@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@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