Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mm: kexec_file_load infinite loop due to unconstrained CMA retry --
commit 897e1cdce0bd14dc7b700f2043c1f14c66a40791 Author: Jinjie Ruan <[email protected]> arm64: kexec_file: Fix CMA page leaks in segment placement retry loops This commit fixes a memory leak in the kexec image placement retry loop. It explicitly releases the associated CMA buffers in the failure paths before the segment count is reduced. > diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c > index b70f4df15a1ae..ffcb7f9075e62 100644 > --- a/arch/arm64/kernel/kexec_image.c > +++ b/arch/arm64/kernel/kexec_image.c > @@ -107,6 +107,7 @@ static void *image_load(struct kimage *image, > * We couldn't find space for the other segments; erase the > * kernel segment and try the next available hole. > */ > + kexec_free_segment_cma(image, kernel_segment_number); > image->nr_segments -= 1; > kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz; > kbuf.mem = KEXEC_BUF_MEM_UNKNOWN; [Severity: High] Does freeing the CMA segment here create an infinite loop? The loop updates kbuf.buf_min to search past the current kernel segment expecting the next kexec_add_buffer() call to allocate from a new hole. However, kexec_alloc_contig() allocates via CMA: kernel/kexec_file.c:kexec_alloc_contig() { ... p = dma_alloc_from_contiguous(NULL, nr_pages, get_order(kbuf->buf_align), true); ... } The underlying CMA allocator completely ignores kbuf->buf_min and kbuf->buf_max. Since the CMA block was just freed, the allocator will repeatedly return the exact same physically contiguous block. If load_other_segments() fails due to layout constraints (like dtb or initrd placement), it will run again with the identical memory layout, fail for the exact same reason, and loop infinitely causing a system hang. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
