Re: [PATCH v3 3/3] iova: defer maple tree erase on GFP_ATOMIC failure
From: Ashok Raj
Date: Sat Jun 20 2026 - 20:08:44 EST
On Tue, Jun 02, 2026 at 11:35:48PM -0400, Rik van Riel wrote:
> From: Rik van Riel <riel@xxxxxxxx>
>
Hi Rik,
I'm a bit rust on these, looking a them after a very long time. So take
my question with a grain of salt :-)
[snip]
> +static void iova_deferred_free_work(struct work_struct *work)
> +{
> + struct delayed_work *dwork = to_delayed_work(work);
> + struct iova_domain *iovad = container_of(dwork, struct iova_domain,
> + deferred_free_work);
> + struct llist_node *list = llist_del_all(&iovad->deferred_frees);
> + struct llist_node *node, *next;
> +
> + llist_for_each_safe(node, next, list) {
> + struct iova *iova = container_of(node, struct iova,
> + deferred_free);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&iovad->iova_lock, flags);
> + if (remove_iova(iovad, iova))
> + free_iova_mem(iova);
> + else
> + llist_add(&iova->deferred_free,
> + &iovad->deferred_frees);
> + spin_unlock_irqrestore(&iovad->iova_lock, flags);
> + }
> +
> + if (!llist_empty(&iovad->deferred_frees))
> + schedule_delayed_work(&iovad->deferred_free_work,
> + msecs_to_jiffies(10));
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.
Should we:
1. A simple retry counter per iova (or a domain-level counter) with a
WARN_ONCE after, say, 10 consecutive failures would at least make the
condition visible.
2. Exponential backoff (10ms → 50ms → 200ms, capped at e.g. 1s) reduces
wasted wakeups under sustained pressure without delaying recovery when
memory frees up quickly.
Cheers,
Ashok