From: Bijan Tabatabai <bijan311@gmail.com>
To: tglx@kernel.org, dave.hansen@linux.intel.com,
mgorman@techsingularity.net, linux-kernel@vger.kernel.org
Cc: mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
sgsu.park@samsung.com, akpm@linux-foundation.org,
Bijan Tabatabai <btabatabai@wisc.edu>
Subject: [PATCH] x86/pkeys: Fix pkey_alloc return value when pkeys are not supported
Date: Thu, 16 Jul 2026 17:06:04 -0500 [thread overview]
Message-ID: <20260716220604.26452-1-bijan311@gmail.com> (raw)
From: Bijan Tabatabai <btabatabai@wisc.edu>
The man page for pkey_alloc(2) specifies that it should return -1 with
the errno set to ENOSPC when pkeys are not supported [1]. However, on
x86 pkey_alloc() sets errno to EINVAL when called for the first time
on a CPU that does not support pkeys.
The root cause of this is the x86 implementation of mm_pkey_alloc() not
directly checking if pkeys are supported. It only checks if all the
pkeys have been allocated by comparing the allocation map against
all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the
initialization of the allocation map, leaving it as 0, while
all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a
pkey available and it returns pkey 0. Then, pkey_alloc() fails with
-EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC.
Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is
left marked as allocated.
Change mm_pkey_alloc() to directly check if OSPKE is enabled, and
return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The
arm64 and powerpc implementations of mm_pkey_alloc() already do this
check.
[1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html
Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls")
Signed-off-by: Bijan Tabatabai <btabatabai@wisc.edu>
---
arch/x86/include/asm/pkeys.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index 06ed2cd2592e..fbb15f6666f1 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -88,6 +88,9 @@ int mm_pkey_alloc(struct mm_struct *mm)
u16 all_pkeys_mask = ((1U << arch_max_pkey()) - 1);
int ret;
+ if (!cpu_feature_enabled(X86_FEATURE_OSPKE))
+ return -1;
+
/*
* Are we out of pkeys? We must handle this specially
* because ffz() behavior is undefined if there are no
--
2.34.1
next reply other threads:[~2026-07-16 22:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 22:06 Bijan Tabatabai [this message]
2026-07-16 22:37 ` Dave Hansen
2026-08-13 17:24 ` [tip: x86/mm] x86/pkeys: Fix pkey_alloc() " tip-bot2 for Bijan Tabatabai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716220604.26452-1-bijan311@gmail.com \
--to=bijan311@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=btabatabai@wisc.edu \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=sgsu.park@samsung.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®