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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Jun 18, 2026 at 10:50:56AM -0400, Liam R. Howlett wrote:

> > If that's the case it should be documented like this too :)
> 
> Yeah, very much should add some notes here... but also maybe stop them
> from doing it by adding this to mas_erase():
> 
> if (mt_external_lock(mas->tree))
>         might_alloc(GFP_KERNEL);

Yeah, and then I'd add a might_alloc() to mtree_erase() as well, it
can always sleep..

> Otherwise, I'll just be telling people they didn't read the docs.

Okay, so to summarize:

- mas_erase, mtree_erase cannot fail with ENOMEM. The check for ENOMEM
  inside should be changed to a WARN_ON to document this.
  Rational: in a GFP_KERNEL context it will sleep forever until it
  gets memory "too small to fail"

- External locks must be sleepable, add a might_alloc() to check for
  that and document. mtree_erase must be sleepable

- 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?

Jason