kernel/git/next/linux-next.git/drivers/gpu/buddy.c, branch master

Merge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.git

2026-07-13T12:09:55+00:00

# Conflicts: # drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h # drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c

gpu/buddy: bail out of try_harder when alignment cannot be honoured

2026-07-09T13:19:49+00:00

The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König Cc: Matthew Auld Cc: Christian König Cc: Timur Kristóf Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld Tested-by: John Olender Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com

gpu/buddy: Track per-order used blocks with a scoreboard

2026-05-29T11:44:01+00:00

Extend the scoreboard approach from the previous commit to used blocks, so drm_buddy_print() can report per-order allocation pressure in O(1). Unlike free blocks, an allocated block can leave the allocated state through mark_free() (normal free and gpu_buddy_block_trim()) or be consumed directly by gpu_block_free() during coalescing. Both sites are guarded by gpu_buddy_block_is_allocated() and paired with the increment in mark_allocated(). v3: - Assert scoreboard is empty at fini(), as sanity check (Matthew Auld) v2: - Update after fix for use-after-free in split_block() call sites - Change goto label to out_free_used_scoreboard for clarity - Make drm_buddy_print() and gpu_buddy_print() symmetric for used and free Assisted-by: GitHub Copilot:claude-sonnet-4.6 Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-6-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Track per-order free blocks with a scoreboard

2026-05-29T11:44:00+00:00

Reporting per-order free block counts in drm_buddy_print() currently requires walking all rbtrees, which is O(n) over the total number of free blocks and holds the allocator lock for the duration. This becomes expensive on large VRAM heaps with many small free fragments. Maintain a free_scoreboard[] array indexed by order instead, so that the count for any order is always available in O(1). The scoreboard is kept accurate by hooking into the four places where a block's free state changes: mark_free(), mark_allocated(), mark_split(), and the sites in __gpu_buddy_free(), __force_merge(), and the four err_undo paths that call rbtree_remove() directly on free blocks without going through mark_*(). The print functions are simplified as a result: the rbtree traversal is replaced by a direct array lookup. v3: Update after introducing __gpu_buddy_undo_splits() helper v2: Update after fix for use-after-free in split_block() call sites Assisted-by: GitHub Copilot:claude-sonnet-4.6 Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-5-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Introduce __gpu_buddy_undo_splits() helper

2026-05-29T11:44:00+00:00

The pattern of merging a block back with its buddy on error paths is duplicated across multiple locations. Extract it into a __gpu_buddy_undo_splits() helper to avoid repetition and prepare for future changes. Suggested-by: Matthew Auld Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-4-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Remove redundant condition in alloc_from_freetree() error path

2026-05-29T11:44:00+00:00

The err_undo label in alloc_from_freetree() is only reachable via a goto from inside the `while (tmp != order)` loop, which means tmp is guaranteed to differ from order at that point. The surrounding `if (tmp != order)` guard was therefore always true and can be dropped without any behavioral change. Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-3-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Fix use-after-free in split_block() call sites

2026-05-29T11:44:00+00:00

When split_block() fails it returns before calling mark_split(), leaving the block in the FREE state and still linked in the rbtree. The four err_undo paths then call __gpu_buddy_free() without first removing the block from the tree, which leads to two distinct bugs: - If the buddy is also free, __gpu_buddy_free() merges the two siblings by calling gpu_block_free(mm, block) while block->rb is still linked in the tree. Any subsequent rbtree traversal will follow the now- dangling pointer, causing a use-after-free. - In alloc_from_freetree(), where there is no buddy guard, __gpu_buddy_free() always reaches mark_free() -> rbtree_insert() with block still in the tree, corrupting the rbtree. The same pattern is already used correctly in __force_merge(): call rbtree_remove() to unlink the block before handing it to __gpu_buddy_free(). Apply the same fix to all four err_undo sites. Reported-by: Sashiko Assisted-by: GitHub Copilot:claude-sonnet-4.6 Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-2-francois.dugast@intel.com Signed-off-by: Francois Dugast

drm/buddy: Integrate lockdep annotations for gpu buddy manager

2026-05-08T13:46:19+00:00

gpu_buddy APIs are expected to be called with the driver-provided lock held, but there is no runtime enforcement of this contract. Add lockdep annotations to catch locking violations early. Introduce gpu_buddy_driver_set_lock() for the driver to register the lock that protects the buddy manager. Add gpu_buddy_driver_lock_held() assertions to all exported gpu_buddy and drm_buddy APIs that access/modify the manager state. The lock_dep_map field is only compiled in when CONFIG_LOCKDEP is enabled, adding zero overhead to production builds. Wire up xe_ttm_vram_mgr to register its mutex with the buddy manager after initialization. Assisted-by: Copilot:claude-opus-4.6 Suggested-by: Matthew Brost Signed-off-by: Tejas Upadhyay Reviewed-by: Matthew Auld Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260508065544.4049240-2-tejas.upadhyay@intel.com

drm/buddy: Improve offset-aligned allocation handling

2026-03-09T07:06:10+00:00

Large alignment requests previously forced the buddy allocator to search by alignment order, which often caused higher-order free blocks to be split even when a suitably aligned smaller region already existed within them. This led to excessive fragmentation, especially for workloads requesting small sizes with large alignment constraints. This change prioritizes the requested allocation size during the search and uses an augmented RB-tree field (subtree_max_alignment) to efficiently locate free blocks that satisfy both size and offset-alignment requirements. As a result, the allocator can directly select an aligned sub-region without splitting larger blocks unnecessarily. A practical example is the VKCTS test dEQP-VK.memory.allocation.basic.size_8KiB.reverse.count_4000, which repeatedly allocates 8 KiB buffers with a 256 KiB alignment. Previously, such allocations caused large blocks to be split aggressively, despite smaller aligned regions being sufficient. With this change, those aligned regions are reused directly, significantly reducing fragmentation. This improvement is visible in the amdgpu VRAM buddy allocator state (/sys/kernel/debug/dri/1/amdgpu_vram_mm). After the change, higher-order blocks are preserved and the number of low-order fragments is substantially reduced. Before: order- 5 free: 1936 MiB, blocks: 15490 order- 4 free: 967 MiB, blocks: 15486 order- 3 free: 483 MiB, blocks: 15485 order- 2 free: 241 MiB, blocks: 15486 order- 1 free: 241 MiB, blocks: 30948 After: order- 5 free: 493 MiB, blocks: 3941 order- 4 free: 246 MiB, blocks: 3943 order- 3 free: 123 MiB, blocks: 4101 order- 2 free: 61 MiB, blocks: 4101 order- 1 free: 61 MiB, blocks: 8018 By avoiding unnecessary splits, this change improves allocator efficiency and helps maintain larger contiguous free regions under heavy offset-aligned allocation workloads. v2:(Matthew) - Update augmented information along the path to the inserted node. v3: - Move the patch to gpu/buddy.c file. v4:(Matthew) - Use the helper instead of calling _ffs directly - Remove gpu_buddy_block_order(block) >= order check and drop order - Drop !node check as all callers handle this already - Return larger than any other possible alignment for __ffs64(0) - Replace __ffs with __ffs64 v5:(Matthew) - Drop subtree_max_alignment initialization at gpu_block_alloc() Signed-off-by: Arunpravin Paneer Selvam Suggested-by: Christian König Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260306060155.2114-1-Arunpravin.PaneerSelvam@amd.com

gpu/buddy: Introduce gpu_buddy_assert() for kunit-aware assertions

2026-03-03T08:07:42+00:00

Introduce gpu_buddy_assert(), a small helper that wraps WARN_ON() and, when CONFIG_KUNIT is enabled, also calls kunit_fail_current_test() so that any active KUnit test is marked as failed. In non-KUnit builds the macro reduces to WARN_ON(), preserving existing behaviour. Stringify the asserted condition in the failure message to make it easy to identify which assertion fired. Leave the WARN_ON() in gpu_buddy_block_trim() unchanged, as it returns -EINVAL and the caller already observes the failure via the return code. Cc: Christian König Cc: Arunpravin Paneer Selvam Suggested-by: Matthew Auld Signed-off-by: Sanjay Yadav Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260227130037.53615-2-sanjay.kumar.yadav@intel.com