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

[Rik van Riel]

On Thu, 2026-06-18 at 13:27 -0400, Liam R. Howlett wrote:
> On 26/06/18 12:24PM, 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?
> 
> The ZERO_ENTRY can be found by mas_* functions and will cause issues
> with the gap searching.  You also have to be careful to handle these
> entries in mas_for_each() loops - you don't want to treat them as
> valid
> entries.
> 
Could it make sense for the maple tree to have
something similar to ZERO_ENTRY that is treated
like a gap, so the gap search can find it, and
get rid of those entries when the gap gets re-used?

-- 
All Rights Reversed.