> During kexec image placement retry loops, any midway failure causes > the loader to truncate `image->nr_segments` back to its initial state > to purge the failed segments. > > However, this truncation introduces a memory leak. The CMA pages > allocated via kexec_add_buffer() during the failed attempt are tracked > in the `image->segment_cma` array. Because the subsequent cleanup paths > only iterate up to the truncated `nr_segments` boundary, these allocated > CMA pages outside the new boundary are permanently leaked. > > Fix this by explicitly releasing the associated CMA buffers in > the failure paths before `image->nr_segments` is reduced.
I looked and how load_other_segments() implements error handling and it seems it really needs more than these fixes. It does not really follow "all or nothing" and it's use of "goto out_err" is quite loosely coupled to actual error handling. The same applies to LoongArch. > Cc: Catalin Marinas <[email protected]> > Cc: Will Deacon <[email protected]> > Cc: Breno Leitao <[email protected]> > Cc: Pratyush Yadav <[email protected]> > Cc: Andrew Morton <[email protected]> > Cc: Yeoreum Yun <[email protected]> > Cc: Baoquan He <[email protected]> > Cc: [email protected] > Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation") > Signed-off-by: Jinjie Ruan <[email protected]> > --- > arch/arm64/kernel/kexec_image.c | 1 + > arch/arm64/kernel/machine_kexec_file.c | 5 ++++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > 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; Sashiko comment about turning the loop into an infinite one seems valid to me: -- Sincerely yours, Mike.
