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

[Rik van Riel <riel@surriel.com>]

On Sat, 2026-06-20 at 17:08 -0700, Ashok Raj wrote:
> 
>   If remove_iova() keeps failing (mas_store_gfp(NULL, GFP_ATOMIC)
> still
>   can't get a maple tree node), the iova is pushed back onto
> deferred_frees
>   and the work reschedules itself at a flat 10ms — forever.  There is
> no
>   retry counter or no backoff.
> 
>   Under sustained memory pressure a device doing frequent unmap could
>   accumulate a growing deferred list, exhaust its IOVA space, and
> start
>   failing DMA map calls — with nothing in dmesg pointing at the real
> cause.
> 
To some extent, yes.

However, if we have GFP_ATOMIC allocations continue
to fail for several seconds, the system will be in
much larger trouble.

Making the condition visible seems like a good idea,
since I don't know if the other GFP_ATOMIC paths that
could cause system hangs output any warnings.

-- 
All Rights Reversed.