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

[Harald Freudenberger <freude@linux.ibm.com>]

On 2025-03-28 11:34, Heiko Carstens wrote:
> 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.
> 

I only compiled this and I wanted to test this today in my
SEL environment. The patch is a suggestion and should trigger
maybe some feedback.

>> -	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.