lkml.org 
[lkml]   [2022]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[RFC PATCH 4/6] pkeys: Lift pkey hardware check for pkey_alloc()
Date
From: Ira Weiny <ira.weiny@intel.com>

pkey_alloc() is documented to return ENOSPC when the hardware does not
support pkeys. On x86, pkey_alloc() incorrectly returns EINVAL.

This is because mm_pkey_alloc() does not check for pkey support before
returning a key. Therefore, if the keys are not exhausted pkey_alloc()
continues on to call arch_set_user_pkey_access(). Unfortunately, when
arch_set_user_pkey_access() detects the failed support it overwrites the
ENOSPC return value with EINVAL.

Ensure consistent behavior across architectures by lifting this check to
the core mm code.

Remove a couple of 'we' references in code comments as well.

Cc: ahaas@chromium.org
Cc: clemensb@chromium.org
Cc: gdeepti@chromium.org
Cc: jkummerow@chromium.org
Cc: manoskouk@chromium.org
Cc: thibaudm@chromium.org
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Sohil Mehta <sohil.mehta@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: linux-api@vger.kernel.org
Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls")
Signed-off-by: Ira Weiny <ira.weiny@intel.com>

---
Thanks to Sohil for pointing out that the commit message could be more
clear WRT how EINVAL is returned incorrectly.
---
arch/powerpc/include/asm/pkeys.h | 8 +++-----
mm/mprotect.c | 3 +++
2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 59a2c7dbc78f..2c8351248793 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -85,18 +85,16 @@ static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
static inline int mm_pkey_alloc(struct mm_struct *mm)
{
/*
- * Note: this is the one and only place we make sure that the pkey is
+ * Note: this is the one and only place to make sure that the pkey is
* valid as far as the hardware is concerned. The rest of the kernel
* trusts that only good, valid pkeys come out of here.
*/
u32 all_pkeys_mask = (u32)(~(0x0));
int ret;

- if (!mmu_has_feature(MMU_FTR_PKEY))
- return -1;
/*
- * Are we out of pkeys? We must handle this specially because ffz()
- * behavior is undefined if there are no zeros.
+ * Out of pkeys? Handle this specially because ffz() behavior is
+ * undefined if there are no zeros.
*/
if (mm_pkey_allocation_map(mm) == all_pkeys_mask)
return -1;
diff --git a/mm/mprotect.c b/mm/mprotect.c
index ba5592655ee3..56d35de33725 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -773,6 +773,9 @@ SYSCALL_DEFINE2(pkey_alloc, unsigned long, flags, unsigned long, init_val)
int pkey;
int ret;

+ if (!arch_pkeys_enabled())
+ return -ENOSPC;
+
/* No flags supported yet. */
if (flags)
return -EINVAL;
--
2.35.1
\
 
 \ /
  Last update: 2022-06-11 01:37    [W:0.386 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site