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 0/1] Remove the need to alloc memory in uv.c
Date: Mon, 31 Mar 2025 12:35:04 +0200	[thread overview]
Message-ID: <20250331103505.15210-1-freude@linux.ibm.com> (raw)

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.

Changelog:
v1: Pre-allocated one page during init of the uv.c code.
v2: As a result of feedback from Heiko about the v1 implementation and
    with another idea of how to deal with a do-not-allocate situation
    in uv.c now another approach: The caller may give a ptr to an
    ephemeral working page if no memory may be allocated.
    Note this patch does not compile as pkey_uv.c needs to get
    adapted to this changed uv function. However, patch is good as a
    starting point for code review and discussions.
    
Harald Freudenberger (1):
  s390/uv: New param workpage for the uv_get_secret_metadata() function

 arch/s390/include/asm/uv.h |  3 ++-
 arch/s390/kernel/uv.c      | 12 +++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)

--
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 Harald Freudenberger [this message]
2025-03-31 10:35 ` [PATCH v2 1/1] s390/uv: New param workpage for the uv_get_secret_metadata() function Harald Freudenberger
2025-03-31 14:55   ` 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-1-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.