| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <113f1d02-69df-b28e-edb9-514d284c6b29@huawei.com>
Date: Thu, 5 Feb 2026 11:15:40 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Sourabh Jain <sourabhjain@...ux.ibm.com>, <corbet@....net>,
<catalin.marinas@....com>, <will@...nel.org>, <chenhuacai@...nel.org>,
<kernel@...0n.name>, <maddy@...ux.ibm.com>, <mpe@...erman.id.au>,
<npiggin@...il.com>, <chleroy@...nel.org>, <pjw@...nel.org>,
<palmer@...belt.com>, <aou@...s.berkeley.edu>, <alex@...ti.fr>,
<tglx@...nel.org>, <mingo@...hat.com>, <bp@...en8.de>,
<dave.hansen@...ux.intel.com>, <hpa@...or.com>, <akpm@...ux-foundation.org>,
<bhe@...hat.com>, <vgoyal@...hat.com>, <dyoung@...hat.com>,
<pawan.kumar.gupta@...ux.intel.com>, <feng.tang@...ux.alibaba.com>,
<kees@...nel.org>, <elver@...gle.com>, <arnd@...db.de>,
<lirongqing@...du.com>, <fvdl@...gle.com>, <leitao@...ian.org>,
<rppt@...nel.org>, <cfsworks@...il.com>, <osandov@...com>, <ardb@...nel.org>,
<ryan.roberts@....com>, <tangyouling@...inos.cn>, <ritesh.list@...il.com>,
<bjorn@...osinc.com>, <songshuaishuai@...ylab.org>,
<samuel.holland@...ive.com>, <kevin.brodsky@....com>,
<junhui.liu@...moral.tech>, <vishal.moola@...il.com>, <coxu@...hat.com>,
<jbohac@...e.cz>, <liaoyuanhong@...o.com>, <brgerst@...il.com>,
<fuqiang.wang@...ystack.cn>, <x86@...nel.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<loongarch@...ts.linux.dev>, <linuxppc-dev@...ts.ozlabs.org>,
<linux-riscv@...ts.infradead.org>, <kexec@...ts.infradead.org>
Subject: Re: [PATCH v3 1/3] crash: Exclude crash kernel memory in crash core
On 2026/2/4 20:32, Sourabh Jain wrote:
>
>
> On 04/02/26 15:07, Jinjie Ruan wrote:
>> The exclude of crashk_res, crashk_low_res and crashk_cma memory
>> are almost identical across different architectures, so handling them
>> in the crash core would eliminate a lot of duplication, so do
>> them in the common code.
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@...wei.com>
>> ---
>> arch/arm64/kernel/machine_kexec_file.c | 12 -------
>> arch/loongarch/kernel/machine_kexec_file.c | 12 -------
>> arch/powerpc/kexec/ranges.c | 16 ++-------
>> arch/riscv/kernel/machine_kexec_file.c | 5 +--
>> arch/x86/kernel/crash.c | 39 ++--------------------
>> kernel/crash_core.c | 28 ++++++++++++++++
>> 6 files changed, 34 insertions(+), 78 deletions(-)
>>
[...]
>> -static int crash_exclude_mem_range_guarded(struct crash_mem
>> **mem_ranges,
>> - unsigned long long mstart,
>> - unsigned long long mend)
>> +static int crash_realloc_mem_range_guarded(struct crash_mem
>> **mem_ranges)
>> {
>> struct crash_mem *tmem = *mem_ranges;
>> @@ -566,7 +564,7 @@ static int
>> crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
>> return -ENOMEM;
>> }
>> - return crash_exclude_mem_range(tmem, mstart, mend);
>> + return 0;
>> }
>> /**
>> @@ -604,18 +602,10 @@ int get_crash_memory_ranges(struct crash_mem
>> **mem_ranges)
>> sort_memory_ranges(*mem_ranges, true);
>> }
>> - /* Exclude crashkernel region */
>> - ret = crash_exclude_mem_range_guarded(mem_ranges,
>> crashk_res.start, crashk_res.end);
>> + ret = crash_realloc_mem_range_guarded(mem_ranges);
>
> What if max_nr_ranges - nr_ranges = 1, then no realloc will happen here.
> And in
> elf_header_exclude_ranges we may not enough space to store additional
> memory ranges needed while excluding one or more CMA ranges.
You're absolutely right — if max_nr_ranges - nr_ranges == 1 we skip the
realloc, yet elf_header_exclude_ranges() can easily need more than one
extra slot.
Thanks for catching this.
Jinjie
>
>> if (ret)
>> goto out;
>> - for (i = 0; i < crashk_cma_cnt; ++i) {
>> - ret = crash_exclude_mem_range_guarded(mem_ranges,
>> crashk_cma_ranges[i].start,
>> - crashk_cma_ranges[i].end);
>> - if (ret)
>> - goto out;
>> - }
>> -
>> /*
>> * FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
>> * regions are exported to save their context at the time of
[...]
>> +static int crash_exclude_mem_ranges(struct crash_mem *cmem)
>> +{
>> + int ret, i;
>> +
>> + /* Exclude crashkernel region */
>> + ret = crash_exclude_mem_range(cmem, crashk_res.start,
>> crashk_res.end);
>> + if (ret)
>> + return ret;
>> +
>> + if (crashk_low_res.end) {
>> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
>> crashk_low_res.end);
>> + if (ret)
>> + return ret;
>> + }
>> + for (i = 0; i < crashk_cma_cnt; ++i) {
>> + ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
>> + crashk_cma_ranges[i].end);
>> + if (ret)
>> + return ret;
>> + }
>> + return ret;
>> +}
>> int crash_prepare_elf64_headers(struct crash_mem *mem, int
>> need_kernel_map,
>> void **addr, unsigned long *sz)
>> @@ -174,6 +197,11 @@ int crash_prepare_elf64_headers(struct crash_mem
>> *mem, int need_kernel_map,
>> unsigned int cpu, i;
>> unsigned long long notes_addr;
>> unsigned long mstart, mend;
>> + int ret;
>> +
>> + ret = crash_exclude_mem_ranges(mem);
>
> I think the assumption here is that mem should have enough space
> to hold the extra ranges created while excluding crash memory ranges.
> Right now, this is not happening on powerpc for the case I mentioned
> in the above comment.
Yes, as you mentioned above.
>
> Also, if crashk_cma_cnt changes in the future, or if a new type of
> crash memory is added, then every architecture would need to adjust
> the mem allocation accordingly. Instead, could we handle this in
> generic code rather than in architecture-specific code, so that we
> always ensure mem has enough space?
I agree — hard-coding the worst-case count in every arch is a
maintenance trap.
Let's move the size calculation (and the realloc if needed) into the
generic crash core so that:
- New CMA regions or future crash-memory types are automatically
accounted for;
- Each architecture no longer has to play whack-a-mole with its private
array size.
Thanks for the suggestion.
>
>> + if (ret)
>> + return ret;
>> /* extra phdr for vmcoreinfo ELF note */
>> nr_phdr = nr_cpus + 1;
>
Powered by blists - more mailing lists