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 <[email protected]> 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/[email protected]?part=2
