Re: [PATCH] KVM: SVM: snp_alloc_firmware_pages: memory leak

[Alexey Kardashevskiy <aik@amd.com>]

On 15/2/25 01:53, Tom Lendacky wrote:
> On 2/13/25 21:59, Alexey Kardashevskiy wrote:
>> Failure to rmpupdate leads to page(s) leak, fix that.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>> ---
>>   drivers/crypto/ccp/sev-dev.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>> index 2e87ca0e292a..0b5f8ab657c5 100644
>> --- a/drivers/crypto/ccp/sev-dev.c
>> +++ b/drivers/crypto/ccp/sev-dev.c
>> @@ -443,8 +443,10 @@ static struct page *__snp_alloc_firmware_pages(gfp_t gfp_mask, int order)
>>   		return page;
>>   
>>   	paddr = __pa((unsigned long)page_address(page));
>> -	if (rmp_mark_pages_firmware(paddr, npages, false))
>> +	if (rmp_mark_pages_firmware(paddr, npages, false)) {
>> +		__free_pages(page, order);
> 
> I'm not sure we can do this. On error, rmp_mark_pages_firmware() attempts
> to cleanup and restore any pages that were marked firmware. But
> snp_reclaim_pages() will leak pages that it can't restore and we don't
> pass back any info to the caller of rmp_mark_pages_firmware() to let it
> know what pages are truly available to free.

oh right. But there is snp_leaked_pages_list which 
__snp_alloc_firmware_pages() could look at.

Or just replace __free_pages() above with:

snp_leak_pages(__page_to_pfn(page), 1 << order)

so memory leak leaves traces in dmesg, at least?


> 
> Thanks,
> Tom
> 
>>   		return NULL;
>> +	}
>>   
>>   	return page;
>>   }

-- 
Alexey