Re: [PATCH v3 2/2] gpu/buddy: search lower orders in contiguous try-harder fallback

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] gpu/buddy: exhaustive anchor search in __alloc_contig_try_harder causes spinlock lockup
--

commit 7497fb4969675f5a56fcaeefb846b3d3c4a2cff7
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>

gpu/buddy: search lower orders in contiguous try-harder fallback

This commit modifies __alloc_contig_try_harder() to descend from the size
order down to min_order. This allows the allocator to build a span from
adjacent lower-order blocks when a single buddy order is empty.

> diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
> index d8e7b79907157..239249362c9ea 100644
> --- a/drivers/gpu/buddy.c
> +++ b/drivers/gpu/buddy.c

[ ... ]

> @@ -1775,6 +1776,12 @@ static int __alloc_contig_try_harder(struct gpu_buddy *mm,
>  		iter = rb_prev(iter);
>  	}
>  
> +next_order:
> +	if (order > min_order) {
> +		order--;
> +		goto retry_order;
> +	}
> +

[Severity: High]
Could this exhaustive anchor search cause a spinlock lockup?

By descending down to min_order (which can be 0), a large contiguous
allocation request under fragmented memory might test up to millions of
order-0 blocks. Because this fallback iterates over all free blocks of a
given order while holding the allocator spinlock, could executing this
many rbtree operations and function calls lead to latency spikes or
watchdog soft lockups?

If untrusted userspace graphics APIs create fragmented VRAM and then
request large contiguous buffer objects (e.g., via
AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS), it appears this path could be
triggered, potentially causing a denial of service. Checking many smaller
anchors instead of only checking anchors sized for the allocation request
increases the worst-case iterations by orders of magnitude.

>  	return -ENOSPC;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006072643.211568-1-arunpravin.paneerselvam@amd.com?part=2