On Tue, Jul 14, 2026 at 09:05:25AM +0530, Aneesh Kumar K.V wrote: > 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.
IMHO it is a horrid API if failure leaves thing in an indeterminate state. For something like this I don't see why the arch FW implementation would be unable to restore things back to as they were on failure. But whatever, everything about set_memory_xx is really bad it could use a cleaning Jason
