[PATCH v3 3/3] iova: defer maple tree erase on GFP_ATOMIC failure

[Jason Gunthorpe]

On Fri, Jun 19, 2026 at 12:54:13AM -0400, Liam R. Howlett wrote:
> On 26/06/18 11:51PM, Rik van Riel wrote:
> > On Thu, 2026-06-18 at 12:24 -0300, Jason Gunthorpe wrote:
> > > 
> > > - I like your idea for Rik to try to store NULL to erase, on failure
> > >   store ZERO_ENTRY, and then set a note on the next alloc to clean
> > > the
> > >   ZERO_ENTRYs?
> > > 
> > Is there any efficient way to find those XA_ZERO_ENTRYs?
> > 
> > Without a good way to find them, we might still need the
> > llist to clean them up, though I agree that cleaning them
> > up from the allocator side looks cleaner than doing it
> > from an external worker, and I did make that change for v4.
> 
> no, but how often is there a failure?  Would walking the list and
> writing NULLs be out of the question (I really don't know, sorry if it's
> a dumb one)?

Yeah, this is what I was thinking. Should never happen? I wouldn't
burn memory in each node to make an emergency recovery run faster.

The idea of keeping track of the high/low along with the flag makes
sense, it will narrow the IOVA range to search.

Jason