diff mbox series

[RFC,3/6] testing/pkeys: Add additional test for pkey_alloc()

Message ID 20220610233533.3649584-4-ira.weiny@intel.com (mailing list archive)
State New
Headers show
Series User pkey minor bug fixes | expand

Commit Message

Ira Weiny June 10, 2022, 11:35 p.m. UTC
From: Ira Weiny <ira.weiny@intel.com>

When pkeys are not available on the hardware pkey_alloc() has specific
behavior which was previously untested.

Add test for this.

Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
 tools/testing/selftests/vm/protection_keys.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Sohil Mehta June 16, 2022, 7:25 p.m. UTC | #1
On 6/10/2022 4:35 PM, ira.weiny@intel.com wrote:
>   
> +void test_pkey_alloc_on_unsupported_cpu(void)
> +{
> +	int test_pkey = sys_pkey_alloc(0, 0);
> +
> +	dprintf1("pkey_alloc: %d (%d %s)\n", test_pkey, errno,
> +		 strerror(errno));
> +	pkey_assert(test_pkey < 0);
> +	pkey_assert(errno == ENOSPC);

This assert fails on a kernel with 
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.

Since pkey_alloc() is an architecture dependent syscall, ENOSYS is 
returned instead of ENOSPC when support is disabled at compile time.
See kernel/sys_ni.c

This brings us to an interesting question.

Should we have different return error codes when compile support is 
disabled vs when runtime support is missing?

Here is the current behavior for pkey_alloc():

No compile time support -> return ENOSYS
No runtime support (but compile time support present) -> return ENOSPC

I would think applications would prefer the same error code. But, I am 
not sure if we can achieve this now due to ABI reasons.


> +}
> +
Dave Hansen June 16, 2022, 8:24 p.m. UTC | #2
On 6/16/22 12:25, Sohil Mehta wrote:
> Should we have different return error codes when compile support is 
> disabled vs when runtime support is missing?

It doesn't *really* matter.  Programs have to be able to run on old
kernels which will return ENOSYS.  So, _when_ new kernels return ENOSYS
or ENOSPC is pretty immaterial.
diff mbox series

Patch

diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c
index 43e47de19c0d..4b733a75606f 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1554,6 +1554,16 @@  void test_implicit_mprotect_exec_only_memory(int *ptr, u16 pkey)
 	do_not_expect_pkey_fault("plain read on recently PROT_EXEC area");
 }
 
+void test_pkey_alloc_on_unsupported_cpu(void)
+{
+	int test_pkey = sys_pkey_alloc(0, 0);
+
+	dprintf1("pkey_alloc: %d (%d %s)\n", test_pkey, errno,
+		 strerror(errno));
+	pkey_assert(test_pkey < 0);
+	pkey_assert(errno == ENOSPC);
+}
+
 void test_mprotect_pkey_on_unsupported_cpu(int *ptr, u16 pkey)
 {
 	int size = PAGE_SIZE;
@@ -1688,6 +1698,8 @@  int main(int argc, char *argv[])
 
 		printf("running PKEY tests for unsupported CPU/OS\n");
 
+		test_pkey_alloc_on_unsupported_cpu();
+
 		ptr  = mmap(NULL, size, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
 		assert(ptr != (void *)-1);
 		test_mprotect_pkey_on_unsupported_cpu(ptr, 1);