From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A84DACCA47B for ; Fri, 10 Jun 2022 23:35:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DA9A8D00E2; Fri, 10 Jun 2022 19:35:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DA828D00F9; Fri, 10 Jun 2022 19:35:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9468D00E2; Fri, 10 Jun 2022 19:35:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 197B38D00F7 for ; Fri, 10 Jun 2022 19:35:44 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E715635DE5 for ; Fri, 10 Jun 2022 23:35:43 +0000 (UTC) X-FDA: 79563935766.21.9CB91B2 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf04.hostedemail.com (Postfix) with ESMTP id 3155240073 for ; Fri, 10 Jun 2022 23:35:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654904141; x=1686440141; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MchtFdici9/LHAAi4sFR4mcD0phAyK+8tBE2Ictb0Iw=; b=MlsOEH6A+4f5IvVac2IUil0POUdmxN+PhXCdyQ86Sw9o5abuVhu1Wc4Q 0G5R9xaTzB3+klVXEjnlqcga2ANy3CTp9MEKe1xr0exRN4FcOdcdGwL6v gyNllFu402490aDogaqbsf3M5S1y9CMQXM/svYpObWV2T07ukGo2u8lwv /RSHoYINBn73OacfczncGr+egRs9C7m5s7z8gMM4vYe+40lbgLxJtr/vt aC1VCxaCzIfqzPe7Vq8/bLS6e2OWhuY6UsJafUcQBDHqyuelp2BwpKsBc hk0OC7NtqNieCs3QurEZ2PcadULoDLk9gJ3638UCQp/DkrwvRLocCNYen Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10374"; a="258214129" X-IronPort-AV: E=Sophos;i="5.91,291,1647327600"; d="scan'208";a="258214129" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2022 16:35:39 -0700 X-IronPort-AV: E=Sophos;i="5.91,291,1647327600"; d="scan'208";a="581302597" Received: from pleung-mobl1.amr.corp.intel.com (HELO localhost) ([10.212.33.34]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2022 16:35:38 -0700 From: ira.weiny@intel.com To: linux-api@vger.kernel.org Cc: Ira Weiny , ahaas@chromium.org, clemensb@chromium.org, gdeepti@chromium.org, jkummerow@chromium.org, manoskouk@chromium.org, thibaudm@chromium.org, Florian Weimer , Sohil Mehta , Andrew Morton , Dave Hansen , "Aneesh Kumar K . V" , x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: [RFC PATCH 4/6] pkeys: Lift pkey hardware check for pkey_alloc() Date: Fri, 10 Jun 2022 16:35:31 -0700 Message-Id: <20220610233533.3649584-5-ira.weiny@intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220610233533.3649584-1-ira.weiny@intel.com> References: <20220610233533.3649584-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654904141; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xuGf3Zw8CoyYfud5Z7iEh5ehVKS4FUO3uYKF7D7uZ+Q=; b=vy1iObLsBhFPqmAbzJfi3lLFUWZU1qGP5BYCWxOdda+o1++iAWSTQNAoQG5rBXs1iJRsGC mhDCtu00q33lKJbfWYLG54e+7qUHzn919En3Q+fBrhUdinfpn3WOdwJ8uOytv8mW7AhlaF IL3ahHWNt169MRNpPQpIZZLxokrHPWc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MlsOEH6A; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=ira.weiny@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654904141; a=rsa-sha256; cv=none; b=o90GjcoEEmB8ye+ITD0tmanUFrxOCHJuEcWc9A0YnN9eI3S7ScjYyQiPgJsoK83kc2rbPv cHhWahvVDSr+MjLEGdPgmMzLxiqKaaicRvrXTBl38z6znKdu6YrjQalHOckK/336+YbAqj ynLcJj8F57R//qf3T4DHKC1+ilyHJy0= X-Stat-Signature: os4wjeteuez1m1yssfi3igdygxzrcwhh X-Rspamd-Queue-Id: 3155240073 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MlsOEH6A; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=ira.weiny@intel.com X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1654904140-984221 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Ira Weiny 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 Cc: Sohil Mehta Cc: Andrew Morton Cc: Dave Hansen Cc: Aneesh Kumar K.V Cc: linux-api@vger.kernel.org Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Ira Weiny --- 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