Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues: - [Medium] Massive SLAB memory allocation in test loop risks OOM failures and softlockups - [Medium] Unrecoverable memory leak on KUnit assertion failures Pre-existing issues: - [High] 32-bit integer truncation in buddy allocator causing out-of-bounds array access and kernel panic -- --- Patch [2]: [PATCH v6 2/2] gpu/tests/buddy: add dirty tracker performance KUnit test --- commit 8a42f0ba9e5529f275dfb03ab95221fffce4cab8 Author: Arunpravin Paneer Selvam <[email protected]> Subject: gpu/tests/buddy: add dirty tracker performance KUnit test This commit adds a new KUnit test to demonstrate the performance benefits of the decoupled dirty-tracker design in the GPU buddy allocator. It evaluates both contiguous allocation latency and repeated allocation throughput under maximal fragmentation. > diff --git a/drivers/gpu/tests/gpu_buddy_test.c > b/drivers/gpu/tests/gpu_buddy_test.c > index e31f368ada951..e37505849ecc7 100644 > --- a/drivers/gpu/tests/gpu_buddy_test.c > +++ b/drivers/gpu/tests/gpu_buddy_test.c [ ... ] > @@ -283,6 +283,115 @@ static void > gpu_test_buddy_fragmentation_performance(struct kunit *test) [ ... ] > +static void gpu_test_buddy_dirty_tracker_performance(struct kunit *test) > +{ [ ... ] > + KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_init(&mm, SZ_4G, SZ_4K), > + "buddy_init failed\n"); > + > + for (i = 0; i < SZ_4G / SZ_4K; i++) > + KUNIT_ASSERT_FALSE_MSG(test, > + gpu_buddy_alloc_blocks(&mm, 0, SZ_4G, > SZ_4K, SZ_4K, > + &allocated, 0), > + "buddy_alloc hit an error size=%u\n", > SZ_4K); [Severity: Medium] Does this loop risk out-of-memory failures and softlockups? Fragmenting a 4 GiB pool into 4 KiB blocks requires 1,048,576 iterations, allocating >2 million struct gpu_buddy_block nodes and later generating 524,288 struct gpu_dirty_extent nodes when alternating blocks are freed. This demands ~225 MB of unswappable SLAB memory, which might trigger OOM failures in memory-constrained KUnit test environments like 128 MB UML instances. Additionally, could a loop of this size without a cond_resched() trigger RCU stalls or softlockups on non-preemptible kernels? [Severity: Medium] Will this lead to an unrecoverable memory leak if the assertion fails? KUNIT_ASSERT_FALSE_MSG aborts the test function immediately. Since the test uses standard kernel allocators instead of KUnit's managed resource API, an allocation failure (such as from the massive SLAB requirements mentioned above) will bypass gpu_buddy_fini() and permanently leak the mm structure's tree nodes and all allocated blocks. > + > + count = 0; > + list_for_each_entry_safe(block, tmp, &allocated, link) { > + if (count++ % 2 == 0) > + list_move_tail(&block->link, &clear_blocks); > + else > + list_move_tail(&block->link, &dirty_blocks); > + } > + > + gpu_buddy_free_list(&mm, &clear_blocks, GPU_BUDDY_CLEARED); > + gpu_buddy_free_list(&mm, &dirty_blocks, 0); > + > + start = ktime_get(); > + KUNIT_ASSERT_FALSE_MSG(test, > + gpu_buddy_alloc_blocks(&mm, 0, SZ_4G, SZ_4G, > SZ_4K, > + &results, > + > GPU_BUDDY_CONTIGUOUS_ALLOCATION), > + "contiguous alloc failed\n"); [Severity: High] This is a pre-existing issue, but does this test request trigger a 32-bit integer truncation in the buddy allocator? When the test asks for a contiguous 4 GiB allocation (SZ_4G), the underlying buddy allocator uses roundup_pow_of_two(size) and rounddown_pow_of_two(size) inside __alloc_contig_try_harder(). Because these macros cast their arguments to unsigned long, passing 4 GiB on a 32-bit platform truncates the size to 0. This results in order = fls(0) - 1 evaluating to UINT_MAX. Could this cause an out-of-bounds array access on mm->free_tree[order] and crash 32-bit CI environments that run this new test suite? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
