Jason Gunthorpe <[email protected]> writes:
> On Wed, Jul 01, 2026 at 11:19:06AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> @@ -115,8 +116,10 @@ static int atomic_pool_expand(struct gen_pool *pool,
>> size_t pool_size,
>> */
>> ret = set_memory_decrypted((unsigned long)page_to_virt(page),
>> 1 << order);
>> - if (ret)
>> + if (ret) {
>> + leak_pages = true;
>> goto remove_mapping;
>> + }
>
> Truely these _set_memory_decrypted() things are an insane API. So a if
> it fails to decrypt it can be in any messy state?
>
Yes, we could possibly try to encrypt the page again and, if that
succeeds, avoid leaking it. We might want to do that tree-wide in a
separate patch.
>
>> @@ -130,14 +133,15 @@ static int atomic_pool_expand(struct gen_pool *pool,
>> size_t pool_size,
>> 1 << order);
>> if (WARN_ON_ONCE(ret)) {
>> /* Decrypt succeeded but encrypt failed, purposely leak */
>> - goto out;
>> + leak_pages = true;
>
> At least this one makes some sense..
>
> Reviewed-by: Jason Gunthorpe <[email protected]>
>
> Jason
-aneesh
