Re: [PATCH v7 02/22] dma-pool: fix page leak in atomic_pool_expand() cleanup
Aneesh Kumar K.V <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
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