From: sashiko-bot@kernel.org
To: "Jinjie Ruan" <ruanjinjie@huawei.com>,
catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
chenhuacai@kernel.org, kernel@xen0n.name, maddy@linux.ibm.com,
mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org,
ritesh.list@gmail.com, sshegde@linux.ibm.com, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com,
akpm@linux-foundation.org, baoquan.he@linux.dev, rppt@kernel.org,
pasha.tatashin@soleen.com, pratyush@kernel.org, thuth@redhat.com,
leitao@debian.org, yeoreum.yun@arm.com, robh@kernel.org,
sourabhjain@linux.ibm.com, kees@kernel.org, coiby.xu@gmail.com,
Yeking@Red54.com, tangyouling@kylinos.cn, maqianga@uniontech.com,
zhangtianyang@loongson.cn, guodongtai@kylinos.cn,
blum@kernel.org, adityag@linux.ibm.com, hui.wang@canonical.com,
sohammetha01@gmail.com, guoren@kernel.org, gaohan@iscas.ac.cn,
kai.huang@intel.com, kas@kernel.org, vishal.l.verma@intel.co m,
piliu@redhat.com, jbouron@amazon.com, mclapinski@google.com,
me@linux.beauty, graf@amazon.com, bgwin@google.com,
x86@kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH v7 05/15] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops
Date: Mon, 26 Oct 2026 10:13:51 +0000 [thread overview]
Message-ID: <sashiko-outbox-184901@kernel.org> (raw)
In-Reply-To: <20261026075201.699550-6-ruanjinjie@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] LoongArch: kexec_file: efi_kexec_load() skips RAM below CMA on retry
--
commit f502069414c135fd39705a4caf6f9bdd9bb1a976
Author: Jinjie Ruan <ruanjinjie@huawei.com>
LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops
This commit fixes CMA page leaks in efi_kexec_load() and
load_other_segments() when segment placement fails, and disables CMA on
retry so kexec_add_buffer() does not repeatedly allocate the same CMA
region.
Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
> diff --git a/arch/loongarch/kernel/kexec_efi.c b/arch/loongarch/kernel/kexec_efi.c
> index 5ee78ebb1546e..d42711b895a2c 100644
> --- a/arch/loongarch/kernel/kexec_efi.c
> +++ b/arch/loongarch/kernel/kexec_efi.c
> @@ -86,6 +86,14 @@ static void *efi_kexec_load(struct kimage *image,
> * We couldn't find space for the other segments; erase the
> * kernel segment and try the next available hole.
> */
> + /*
> + * kexec_alloc_contig() ignores buf_min, so disable CMA to
> + * let the retry make progress.
> + */
> + if (image->segment_cma[kernel_segment_number])
> + image->no_cma = true;
> +
> + 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: Medium]
When falling back from a CMA allocation to a normal bottom-up System RAM
search in efi_kexec_load(), does advancing kbuf.buf_min skip valid System
RAM located below the CMA region?
Before the retry loop in efi_kexec_load(), kbuf is set up for a bottom-up
search starting at text_offset:
kbuf.top_down = false;
...
kbuf.buf_min = text_offset;
On the first iteration, kexec_add_buffer() -> kexec_locate_mem_hole() ->
kexec_alloc_contig() allocates the kernel segment from CMA, which ignores
kbuf.buf_min and may place the kernel high in physical memory (for example,
near the top of DRAM or above 4GB).
If load_other_segments() then fails to place the initrd because there is
not enough space above the CMA kernel segment, the retry path sets
image->no_cma = true so the next iteration falls back to
kexec_walk_memblock(). However, it still updates kbuf.buf_min:
kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
Because the first attempt came from CMA rather than a bottom-up walk from
text_offset, won't advancing kbuf.buf_min past the CMA allocation skip all
System RAM in [text_offset, kernel_segment->mem + kernel_segment->memsz)
and cause kexec_file_load() to fail with -EADDRNOTAVAIL?
Should kbuf.buf_min only be advanced when the failed kernel segment was not
allocated from CMA?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261026075201.699550-1-ruanjinjie@huawei.com?part=5
next prev parent reply other threads:[~2026-10-26 10:13 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 7:51 [PATCH v7 00/15] kexec: Fix CMA and elf header leaks and rework Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 7:51 ` [PATCH v7 01/15] arm64: kexec_file: Stop using the Image text_offset Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 9:32 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 02/15] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 9:41 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 03/15] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 9:53 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 04/15] arm64: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:00 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 05/15] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:13 ` sashiko-bot [this message]
2026-10-26 7:51 ` [PATCH v7 06/15] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:21 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 07/15] LoongArch: kexec_file: Fix a modified_cmdline leak Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:28 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 08/15] arm64: kexec_file: Simplify load_other_segments() Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:32 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 09/15] LoongArch: " Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:40 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 10/15] riscv: kexec_file: Simplify load_extra_segments() Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:42 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 11/15] kexec: Free the elf core header in kimage_file_post_load_cleanup() Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:47 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 12/15] kexec: Add kexec_load_other_segments() helper Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 10:56 ` sashiko-bot
2026-10-26 7:51 ` [PATCH v7 13/15] arm64: kexec_file: Use kexec_load_other_segments() to simplify code Jinjie Ruan
2026-10-26 7:51 ` Jinjie Ruan
2026-10-26 11:01 ` sashiko-bot
2026-10-26 7:52 ` [PATCH v7 14/15] LoongArch: " Jinjie Ruan
2026-10-26 7:52 ` Jinjie Ruan
2026-10-26 11:12 ` sashiko-bot
2026-10-26 7:52 ` [PATCH v7 15/15] riscv: " Jinjie Ruan
2026-10-26 7:52 ` Jinjie Ruan
2026-10-26 11:21 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-184901@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Yeking@Red54.com \
--cc=adityag@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baoquan.he@linux.dev \
--cc=blum@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=coiby.xu@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=gaohan@iscas.ac.cn \
--cc=guodongtai@kylinos.cn \
--cc=guoren@kernel.org \
--cc=hpa@zytor.com \
--cc=hui.wang@canonical.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@xen0n.name \
--cc=leitao@debian.org \
--cc=maddy@linux.ibm.com \
--cc=maqianga@uniontech.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=pjw@kernel.org \
--cc=pratyush@kernel.org \
--cc=ritesh.list@gmail.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sohammetha01@gmail.com \
--cc=sourabhjain@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tangyouling@kylinos.cn \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=vishal.l.verma@intel.co \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
--cc=zhangtianyang@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.