All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Freudenberger <freude@linux.ibm.com>
To: seiden@linux.ibm.com, borntraeger@linux.ibm.com,
	frankja@linux.ibm.com, imbrenda@linux.ibm.com, hca@linux.ibm.com
Cc: linux-s390@vger.kernel.org
Subject: [PATCH v2 1/1] s390/uv: New param workpage for the uv_get_secret_metadata() function
Date: Mon, 31 Mar 2025 12:35:05 +0200	[thread overview]
Message-ID: <20250331103505.15210-2-freude@linux.ibm.com> (raw)
In-Reply-To: <20250331103505.15210-1-freude@linux.ibm.com>

The pkey uv handler may be called in a do-not-allocate memory
situation. For example when an encrypted swap file is used and the
encryption is done via UV retrievable secrets with protected keys.

The pkey uv handler calls uv_get_secret_metadata() and thus has a need
to have this function work without memory allocations. So this patch
extends the uv_get_secret_metadata() function to be able to work on
a provided working page instead of allocating/freeing memory via
kmalloc/kfree:

int uv_get_secret_metadata(const u8 secret_id[UV_SECRET_ID_LEN],
			   struct uv_secret_list_item_hdr *secret,
			   u8 *workpage);

Parameter workpage is a ephemeral working page used by the function.
If given (!= NULL), it needs to point to memory of at least PAGE_SIZE
bytes. If NULL, the function uses kmalloc/kfree to allocate and free a
working buffer.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
---
 arch/s390/include/asm/uv.h |  3 ++-
 arch/s390/kernel/uv.c      | 12 +++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/s390/include/asm/uv.h b/arch/s390/include/asm/uv.h
index b11f5b6d0bd1..496cd9c9f2a5 100644
--- a/arch/s390/include/asm/uv.h
+++ b/arch/s390/include/asm/uv.h
@@ -617,7 +617,8 @@ static inline int uv_remove_shared(unsigned long addr)
 }
 
 int uv_get_secret_metadata(const u8 secret_id[UV_SECRET_ID_LEN],
-			   struct uv_secret_list_item_hdr *secret);
+			   struct uv_secret_list_item_hdr *secret,
+			   u8 *workpage);
 int uv_retrieve_secret(u16 secret_idx, u8 *buf, size_t buf_size);
 
 extern int prot_virt_host;
diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
index 9f05df2da2f7..0a8a6bc19c49 100644
--- a/arch/s390/kernel/uv.c
+++ b/arch/s390/kernel/uv.c
@@ -713,6 +713,9 @@ static int find_secret(const u8 secret_id[UV_SECRET_ID_LEN],
  * uv_get_secret_metadata() - get secret metadata for a given secret id.
  * @secret_id: search pattern.
  * @secret: output data, containing the secret's metadata.
+ * @workpage: ephemeral working page. Caller may give a ptr to one page
+ *            here as ephemeral working buffer. If NULL, kmalloc is used
+ *            to alloc a working buffer.
  *
  * Search for a secret with the given secret_id in the Ultravisor secret store.
  *
@@ -725,16 +728,19 @@ static int find_secret(const u8 secret_id[UV_SECRET_ID_LEN],
  * * %EIO:	- Other unexpected UV error.
  */
 int uv_get_secret_metadata(const u8 secret_id[UV_SECRET_ID_LEN],
-			   struct uv_secret_list_item_hdr *secret)
+			   struct uv_secret_list_item_hdr *secret,
+			   u8 *workpage)
 {
 	struct uv_secret_list *buf;
 	int rc;
 
-	buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+	buf = workpage ? (struct uv_secret_list *)workpage :
+		kzalloc(sizeof(*buf), GFP_KERNEL);
 	if (!buf)
 		return -ENOMEM;
 	rc = find_secret(secret_id, buf, secret);
-	kfree(buf);
+	if (!workpage)
+		kfree(buf);
 	return rc;
 }
 EXPORT_SYMBOL_GPL(uv_get_secret_metadata);
-- 
2.43.0


  reply	other threads:[~2025-03-31 10:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 10:35 [PATCH v2 0/1] Remove the need to alloc memory in uv.c Harald Freudenberger
2025-03-31 10:35 ` Harald Freudenberger [this message]
2025-03-31 14:55   ` [PATCH v2 1/1] s390/uv: New param workpage for the uv_get_secret_metadata() function Heiko Carstens
2025-04-01 12:54     ` Harald Freudenberger

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=20250331103505.15210-2-freude@linux.ibm.com \
    --to=freude@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=seiden@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.