| Message ID | 1528937115-10132-19-git-send-email-linuxram@us.ibm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
On 06/13/2018 05:45 PM, Ram Pai wrote: > /* > - * There are 16 pkeys supported in hardware. Three are > - * allocated by the time we get here: > - * 1. The default key (0) > - * 2. One possibly consumed by an execute-only mapping. > - * 3. One allocated by the test code and passed in via > - * 'pkey' to this function. > - * Ensure that we can allocate at least another 13 (16-3). > + * There are NR_PKEYS pkeys supported in hardware. arch_reserved_keys() > + * are reserved. One of which is the default key(0). One can be taken > + * up by an execute-only mapping. > + * Ensure that we can allocate at least the remaining. > */ > - pkey_assert(i >= NR_PKEYS-3); > + pkey_assert(i >= (NR_PKEYS-arch_reserved_keys()-1)); We recently had a bug here. I fixed it and left myself a really nice comment so I and others wouldn't screw it up in the future. Does this kill my nice, new comment? -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 20, 2018 at 08:11:07AM -0700, Dave Hansen wrote: > On 06/13/2018 05:45 PM, Ram Pai wrote: > > /* > > - * There are 16 pkeys supported in hardware. Three are > > - * allocated by the time we get here: > > - * 1. The default key (0) > > - * 2. One possibly consumed by an execute-only mapping. > > - * 3. One allocated by the test code and passed in via > > - * 'pkey' to this function. > > - * Ensure that we can allocate at least another 13 (16-3). > > + * There are NR_PKEYS pkeys supported in hardware. arch_reserved_keys() > > + * are reserved. One of which is the default key(0). One can be taken > > + * up by an execute-only mapping. > > + * Ensure that we can allocate at least the remaining. > > */ > > - pkey_assert(i >= NR_PKEYS-3); > > + pkey_assert(i >= (NR_PKEYS-arch_reserved_keys()-1)); > > We recently had a bug here. I fixed it and left myself a really nice > comment so I and others wouldn't screw it up in the future. > > Does this kill my nice, new comment? part of your nice comment has been moved into the header file. The arch specific header file explains where and how the reserved keys are used.
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c index cb81a47..e8ad970 100644 --- a/tools/testing/selftests/vm/protection_keys.c +++ b/tools/testing/selftests/vm/protection_keys.c @@ -1175,15 +1175,12 @@ void test_pkey_alloc_exhaust(int *ptr, u16 pkey) pkey_assert(i < NR_PKEYS*2); /* - * There are 16 pkeys supported in hardware. Three are - * allocated by the time we get here: - * 1. The default key (0) - * 2. One possibly consumed by an execute-only mapping. - * 3. One allocated by the test code and passed in via - * 'pkey' to this function. - * Ensure that we can allocate at least another 13 (16-3). + * There are NR_PKEYS pkeys supported in hardware. arch_reserved_keys() + * are reserved. One of which is the default key(0). One can be taken + * up by an execute-only mapping. + * Ensure that we can allocate at least the remaining. */ - pkey_assert(i >= NR_PKEYS-3); + pkey_assert(i >= (NR_PKEYS-arch_reserved_keys()-1)); for (i = 0; i < nr_allocated_pkeys; i++) { err = sys_pkey_free(allocated_pkeys[i]);
The maximum number of keys that can be allocated has to take into consideration, that some keys are reserved by the architecture for specific purpose. Hence cannot be allocated. Fix the assertion in test_pkey_alloc_exhaust() cc: Dave Hansen <dave.hansen@intel.com> cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: Ram Pai <linuxram@us.ibm.com> --- tools/testing/selftests/vm/protection_keys.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-)