Re: [PATCH v1 1/1] s390/uv: Prealloc and use one work page

Heiko Carstens
2025-03-28T10:34:42Z

On Thu, Mar 27, 2025 at 04:38:24PM +0100, Harald Freudenberger wrote:
> The pkey handler is calling the uv in some circumstances
> where no memory allocation is acceptable. As of now only
> the uv_get_secret_metadata() function allocates memory.
> As this is exactly one page, lets introduce a pre-allocated
> work page and protect the concurrent use with a mutex to
> remove dynamic memory allocation and free. This page may be
> also used with future extension to the uv code.
>
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> ---
> arch/s390/kernel/uv.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)

[adding maintainers, according to get_maintainer.pl]

> static int __init uv_init(phys_addr_t stor_base, unsigned long stor_len)
> {
> struct uv_cb_init uvcb = {
> @@ -61,6 +68,12 @@ void __init setup_uv(void)
> if (!is_prot_virt_host())
> return;
>
> + work_page = (u8 *)__get_free_page(GFP_KERNEL);
> + if (!work_page) {
> + pr_warn("Failed to alloc a working memory page\n");
> + return;
> + }
> +
> uv_stor_base = memblock_alloc_try_nid(

Did you test this? I think this cannot work. When setup_uv() is called
the buddy allocator is not yet initialized.
Please use memblock_alloc_or_panic() instead.

> - buf = kzalloc(sizeof(*buf), GFP_KERNEL);
> - if (!buf)
> - return -ENOMEM;
> + mutex_lock(&work_page_lock);
> + buf = (struct uv_secret_list *)work_page;
> rc = find_secret(secret_id, buf, secret);
> - kfree(buf);
> + mutex_unlock(&work_page_lock);

The commit message does not explain why memory allocation is not
acceptable. Usually this translates to non-sleepable context. If that
is the case, then using a mutex would be wrong. This needs to be
clarified.

> +
> return rc;

Unrelated whitespace change.

It is up to the kvm folks to decide if the whole approach is ok.