linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ira.weiny@intel.com
To: linux-api@vger.kernel.org
Cc: Ira Weiny <ira.weiny@intel.com>,
	Sohil Mehta <sohil.mehta@intel.com>,
	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 0/6] User pkey minor bug fixes
Date: Fri, 10 Jun 2022 16:35:27 -0700	[thread overview]
Message-ID: <20220610233533.3649584-1-ira.weiny@intel.com> (raw)

From: Ira Weiny <ira.weiny@intel.com>


While evaluating the possibility of defining a new type for pkeys within the
kernel I found a couple of minor bugs.

Because these patches clean up the return codes from system calls I'm sending
this out RFC hoping that users will speak up if anything breaks.

I'm not too concerned about pkey_free() because it is unlikely that anyone is
checking the return code.  Interestingly enough, glibc recommends not calling
pkey_free() because it does not change the access rights to the key and may be
subsequently allocated again.[1][2]

The pkey_alloc() is more concerning.  However, I checked the Chrome source and
it does not differentiate among the return codes and maps all errors into
kNoMemoryProtectionKey.

glibc says it returns ENOSYS if the system does not support pkeys but I don't
see where ENOSYS is returned?  AFAICS it just returns what the kernel returns.
So it is probably up to user of glibc.

In addition I've enhanced the pkey tests to verify and test the changes.

Thanks to Rick Edgecombe and Sohil Mehta for internal review.


[1] Quote from manual/memory.texi:

Calling this function does not change the access rights of the freed
protection key.  The calling thread and other threads may retain access
to it, even if it is subsequently allocated again.  For this reason, it
is not recommended to call the @code{pkey_free} function.

[2] PKS had a similar issue and went to statically allocated keys instead.


Ira Weiny (6):
  testing/pkeys: Add command line options
  testing/pkeys: Don't use uninitialized variable
  testing/pkeys: Add additional test for pkey_alloc()
  pkeys: Lift pkey hardware check for pkey_alloc()
  pkeys: Up level pkey_free() checks
  pkeys: Change mm_pkey_free() to void

 arch/powerpc/include/asm/pkeys.h             | 18 ++---
 arch/x86/include/asm/pkeys.h                 |  7 +-
 include/linux/pkeys.h                        |  5 +-
 mm/mprotect.c                                | 13 +++-
 tools/testing/selftests/vm/pkey-helpers.h    |  7 +-
 tools/testing/selftests/vm/protection_keys.c | 75 +++++++++++++++++---
 6 files changed, 86 insertions(+), 39 deletions(-)


base-commit: 874c8ca1e60b2c564a48f7e7acc40d328d5c8733
-- 
2.35.1


             reply	other threads:[~2022-06-10 23:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 23:35 ira.weiny [this message]
2022-06-10 23:35 ` [RFC PATCH 1/6] testing/pkeys: Add command line options ira.weiny
2022-06-13 22:31   ` Sohil Mehta
2022-06-13 23:41     ` Ira Weiny
2022-06-10 23:35 ` [RFC PATCH 2/6] testing/pkeys: Don't use uninitialized variable ira.weiny
2022-06-13 22:48   ` Sohil Mehta
2022-06-13 23:59     ` Ira Weiny
2022-06-10 23:35 ` [RFC PATCH 3/6] testing/pkeys: Add additional test for pkey_alloc() ira.weiny
2022-06-16 19:25   ` Sohil Mehta
2022-06-16 20:24     ` Dave Hansen
2022-06-10 23:35 ` [RFC PATCH 4/6] pkeys: Lift pkey hardware check " ira.weiny
2022-06-16 19:31   ` Sohil Mehta
2022-06-10 23:35 ` [RFC PATCH 5/6] pkeys: Up level pkey_free() checks ira.weiny
2022-06-13  9:14   ` Christophe Leroy
2022-06-10 23:35 ` [RFC PATCH 6/6] pkeys: Change mm_pkey_free() to void ira.weiny
2022-06-13  9:17   ` Christophe Leroy
2022-06-13 16:16     ` Ira Weiny
2022-06-13 22:05 ` [RFC PATCH 0/6] User pkey minor bug fixes Sohil Mehta

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=20220610233533.3649584-1-ira.weiny@intel.com \
    --to=ira.weiny@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sohil.mehta@intel.com \
    --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;
as well as URLs for NNTP newsgroup(s).