From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: <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>, <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>, <pasha.tatashin@soleen.com>,
<pratyush@kernel.org>, <ruirui.yang@linux.dev>, <kees@kernel.org>,
<thuth@redhat.com>, <gshan@redhat.com>, <jic23@kernel.org>,
<james.morse@arm.com>, <ardb@kernel.org>, <leitao@debian.org>,
<yeoreum.yun@arm.com>, <sourabhjain@linux.ibm.com>,
<coxu@redhat.com>, <tangyouling@kylinos.cn>,
<hbathini@linux.ibm.com>, <adityag@linux.ibm.com>,
<ionut.nechita@windriver.com>, <liaoyuanhong@vivo.com>,
<seanjc@google.com>, <fuqiang.wang@easystack.cn>,
<makb@juniper.net>, <piliu@redhat.com>, <ebiggers@kernel.org>,
<jbouron@amazon.com>, <mclapinski@google.com>, <me@linux.beauty>,
<graf@amazon.com>, <bgwin@google.com>, <robh@kernel.org>,
<takahiro.akashi@linaro.org>, <palmer@rivosinc.com>,
<x86@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <loongarch@lists.linux.dev>,
<linuxppc-dev@lists.ozlabs.org>, <kexec@lists.infradead.org>,
<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH v3 01/17] kexec: Record allocated CMA pages to fix release size mismatch
Date: Wed, 2 Sep 2026 09:10:16 +0800 [thread overview]
Message-ID: <bf0e158e-4bd0-4495-a9e2-983556e4041b@huawei.com> (raw)
In-Reply-To: <178829364020.3691424.12323275610442178748.b4-review@b4>
在 2026/9/2 4:14, Mike Rapoport 写道:
> Hi,
>
>> The CMA pages allocated for a kexec segment are released using the
>> segment's memsz to calculate the number of pages. However, some
>> architecture loaders modify the segment's memsz after allocation
>> (e.g. arm64 subtracts text_offset), causing the release function to
>> free fewer pages than were originally allocated, leaking the remaining
>> CMA pages.
>>
>> Add a per-segment `segment_cma_pages` array to store the number of
>> pages actually allocated from CMA. Populate it during
>> kexec_add_buffer() using the aligned memsz, and use it in
>> kimage_free_cma() to accurately release all allocated pages.
>>
>> This avoids relying on the potentially modified segment->memsz and
>> prevents silent CMA memory leaks.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Baoquan He <baoquan.he@linux.dev>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
>> Cc: Pratyush Yadav <pratyush@kernel.org>
>> Cc: Brian Mak <makb@juniper.net>
>> Cc: Pingfan Liu <piliu@redhat.com>
>> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
>> Cc: Justinien Bouron <jbouron@amazon.com>
>> Cc: Li Chen <me@linux.beauty>
>> Cc: stable@vger.kernel.org
>> Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
>> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>>
>> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
>> index 0af8ae4fdd087..83c296c0eb6cc 100644
>> --- a/include/linux/kexec.h
>> +++ b/include/linux/kexec.h
>> @@ -349,6 +349,7 @@ struct kimage {
>> unsigned long nr_segments;
>> struct kexec_segment segment[KEXEC_SEGMENT_MAX];
>> struct page *segment_cma[KEXEC_SEGMENT_MAX];
>> + unsigned int segment_cma_pages[KEXEC_SEGMENT_MAX];
>
> Can we universally use unsigned long for number of pages?
Hi Mike,
unsigned int is used here because the second parameter of
arch_kexec_pre_free_pages is unsigned int.
static inline void arch_kexec_pre_free_pages(void *vaddr, unsigned int
pages) { }
>
>>
>> struct list_head control_pages;
>> struct list_head dest_pages;
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index dc770b9a6d053..611b15bb1369e 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -560,7 +560,7 @@ static void kimage_free_cma(struct kimage *image)
>>
>> for (i = 0; i < image->nr_segments; i++) {
>> struct page *cma = image->segment_cma[i];
>> - u32 nr_pages = image->segment[i].memsz >> PAGE_SHIFT;
>> + unsigned int nr_pages = image->segment_cma_pages[i];
>>
>> if (!cma)
>> continue;
>> @@ -568,6 +568,7 @@ static void kimage_free_cma(struct kimage *image)
>> arch_kexec_pre_free_pages(page_address(cma), nr_pages);
>> dma_release_from_contiguous(NULL, cma, nr_pages);
>> image->segment_cma[i] = NULL;
>> + image->segment_cma_pages[i] = 0;
>> }
>>
>> }
>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>> index 59fb9d71e9d86..bfae3fee7f2f9 100644
>> --- a/kernel/kexec_file.c
>> +++ b/kernel/kexec_file.c
>> @@ -670,7 +670,7 @@ static int kexec_walk_resources(struct kexec_buf *kbuf,
>>
>> static int kexec_alloc_contig(struct kexec_buf *kbuf)
>> {
>> - size_t nr_pages = kbuf->memsz >> PAGE_SHIFT;
>> + size_t nr_pages = PFN_DOWN(kbuf->memsz);
>> unsigned long mem;
>> struct page *p;
>>
>> @@ -756,6 +756,8 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
>> */
>> int kexec_add_buffer(struct kexec_buf *kbuf)
>> {
>> + unsigned long nr_segments = kbuf->image->nr_segments;
>> + size_t nr_pages;
>> struct kexec_segment *ksegment;
>> int ret;
>>
>> @@ -763,7 +765,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>> if (!kbuf->image->file_mode)
>> return -EINVAL;
>>
>> - if (kbuf->image->nr_segments >= KEXEC_SEGMENT_MAX)
>> + if (nr_segments >= KEXEC_SEGMENT_MAX)
>> return -EINVAL;
>>
>> /*
>> @@ -789,12 +791,18 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>> return ret;
>>
>> /* Found a suitable memory range */
>> - ksegment = &kbuf->image->segment[kbuf->image->nr_segments];
>> + ksegment = &kbuf->image->segment[nr_segments];
>> ksegment->kbuf = kbuf->buffer;
>> ksegment->bufsz = kbuf->bufsz;
>> ksegment->mem = kbuf->mem;
>> ksegment->memsz = kbuf->memsz;
>> - kbuf->image->segment_cma[kbuf->image->nr_segments] = kbuf->cma;
>> + kbuf->image->segment_cma[nr_segments] = kbuf->cma;
>> + if (kbuf->cma) {
>> + nr_pages = (unsigned int)(PFN_DOWN(kbuf->memsz));
>> + kbuf->image->segment_cma_pages[nr_segments] = nr_pages;
> kbuf->image->segment_cma_pages[nr_segments] = nr_pages;
>> + } else {
>> + kbuf->image->segment_cma_pages[nr_segments] = 0;
>> + }
>
> I suggest to rename nr_pages to nr_cma_pages, initialize it to 0 at
> declaration time and make this
I agree with this.
>
> if (kbuf->cma)
> nr_cma_pages = PFN_DOWN(kbuf->memsz);
> kbuf->image->segment_cma_pages[nr_segments] = nr_cma_pages;
>
next prev parent reply other threads:[~2026-09-02 1:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 9:25 [PATCH v3 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 01/17] kexec: Record allocated CMA pages to fix release size mismatch Jinjie Ruan
2026-09-01 20:14 ` Mike Rapoport
2026-09-02 1:10 ` Jinjie Ruan [this message]
2026-08-26 9:25 ` [PATCH v3 02/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Jinjie Ruan
2026-09-01 20:14 ` Mike Rapoport
2026-08-26 9:25 ` [PATCH v3 03/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 04/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 05/17] LoongArch: kexec: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
2026-08-31 14:09 ` Huacai Chen
2026-09-01 1:41 ` Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 06/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 07/17] crash_dump: Fix potential double-free of keys_header Jinjie Ruan
2026-08-30 5:59 ` Sourabh Jain
2026-08-31 1:24 ` Jinjie Ruan
2026-08-31 13:36 ` Coiby Xu
2026-08-26 9:25 ` [PATCH v3 08/17] crash: Extract crash_get_memory_ranges() helper Jinjie Ruan
2026-09-01 20:14 ` Mike Rapoport
2026-08-26 9:25 ` [PATCH v3 09/17] crash: Fix TOCTOU race in crash memory range collection Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 10/17] elf: Introduce elf64_phdr_size() helper Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 11/17] crash: Introduce crash_extra_elfcorehdr_size() helper Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 12/17] x86/crash: Use num_possible_cpus() for elfcorehdr size Jinjie Ruan
2026-09-02 6:14 ` Sourabh Jain
2026-09-02 10:01 ` Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 13/17] crash: Improve elfcorehdr segment identification Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 14/17] x86/crash: Simplify crash_load_segments() using crash_extra_elfcorehdr_size() Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 15/17] crash: Simplify CRASH_MAX_MEMORY_RANGES handling Jinjie Ruan
2026-09-01 20:14 ` Mike Rapoport
2026-09-02 1:19 ` Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 16/17] arm64: kexec_file: Simplify load_other_segments() Jinjie Ruan
2026-08-26 9:25 ` [PATCH v3 17/17] arm64: crash: Add crash hotplug support Jinjie Ruan
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=bf0e158e-4bd0-4495-a9e2-983556e4041b@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=adityag@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=bgwin@google.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=coxu@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@kernel.org \
--cc=fuqiang.wang@easystack.cn \
--cc=graf@amazon.com \
--cc=gshan@redhat.com \
--cc=hbathini@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=ionut.nechita@windriver.com \
--cc=james.morse@arm.com \
--cc=jbouron@amazon.com \
--cc=jic23@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@xen0n.name \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=liaoyuanhong@vivo.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=maddy@linux.ibm.com \
--cc=makb@juniper.net \
--cc=mark.rutland@arm.com \
--cc=mclapinski@google.com \
--cc=me@linux.beauty \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=palmer@rivosinc.com \
--cc=pasha.tatashin@soleen.com \
--cc=piliu@redhat.com \
--cc=pratyush@kernel.org \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=seanjc@google.com \
--cc=sourabhjain@linux.ibm.com \
--cc=takahiro.akashi@linaro.org \
--cc=tangyouling@kylinos.cn \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yeoreum.yun@arm.com \
/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.