Re: [PATCH 2/2] iommufd: Periodically reschedule when unmapping

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `cond_resched()` rate limiter is circumvented for fragmented memory because the loop counter `i` is local and resets on every batch, leaving the scheduler warning unresolved.
- [High] Using `BIT(PUD_ORDER)` to rate-limit `cond_resched()` to 1GB is unportable and scales incorrectly on architectures with larger page sizes, preventing rescheduling.
--

--- Patch [2]: [PATCH 2/2] iommufd: Periodically reschedule when unmapping ---
commit 32d4b71fc4dce755ccc1bb27abe57a685f82b576
Author: Aaron Lewis <aaronlewis@google.com>

iommufd: Periodically reschedule when unmapping

This patch adds a cond_resched() call to batch_from_domain() to avoid
scheduler warnings during large DMA unmaps. It attempts to rate-limit
the yields to approximately once per 1GB of processed memory.

> diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
> index 03c8379bbc347..e7abb3350b235 100644
> --- a/drivers/iommu/iommufd/pages.c
> +++ b/drivers/iommu/iommufd/pages.c
> @@ -412,6 +412,7 @@ static void batch_from_domain(struct pfn_batch *batch,
>  	unsigned int page_offset = 0;
>  	unsigned long iova;
>  	phys_addr_t phys;
> +	int i = 0;
>  
>  	iova = iopt_area_index_to_iova(area, start_index);
>  	if (start_index == iopt_area_index(area))
> @@ -428,6 +429,9 @@ static void batch_from_domain(struct pfn_batch *batch,
>  		iova += PAGE_SIZE - page_offset;
>  		page_offset = 0;
>  		start_index++;
> +
> +		if ((++i % BIT(PUD_ORDER)) == 0)
> +			cond_resched();

[Severity: High]
Does this regression mean the counter fails to trigger cond_resched() when
operating on fragmented memory?

Because i is a local variable, it resets to 0 on every call to
batch_from_domain(). For highly fragmented memory, batch_add_pfn() will
fill its array and return false early (limited to roughly 5,461 pages by
TEMP_MEMORY_LIMIT).

This early return causes the outer loops, such as iopt_area_unpin_domain(),
to repeatedly call batch_from_domain(). This continuously resets i to 0
before it can ever reach the threshold, meaning cond_resched() is never
called and scheduler lockups can still occur.

[Severity: High]
Is this a regression on architectures where BIT(PUD_ORDER) does not equal 1GB?

The commit message mentions limiting the cond_resched() call to once per 1GB.
While this holds true on architectures like x86_64, it scales incorrectly
on architectures with larger page sizes.

For example, on ARM64 with 64KB pages and 3-level page tables, PUD_ORDER
is 26. BIT(26) iterations of 64KB pages corresponds to 4TB of memory,
not 1GB. The loop will only yield once every 4TB, which effectively defeats
the mitigation on these architectures.

>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714210303.3967981-1-aaronlewis@google.com?part=2