From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E57BA399031; Mon, 1 Jun 2026 09:48:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307335; cv=none; b=ZOR18LMd7Hawx2rFOTZx4hQt73oNHGKHng4F7gAlkd7Lotn8m8ozjPsFgScTdhuIpOnFRRBq+xVKYnjbzFiwOGZPuM2/FiN9TNTlSKCRSkpYWQR8WZmOfokUa8wnflLoGrLdbZ6gGgXr9RBAHVXNajbCIrBCMjRjn6NrPVmInFA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307335; c=relaxed/simple; bh=mTUcFKsbwiD0LIrg49RZV6ZL6jdqAvgndaKIqOJxJTc=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JJ6hBNA5V9xC0jIhmRpm5LCPFpmHKXRUGhB6UNkPYSjLE/v9vosG1dPttTa/pFb1a9QeY2Lcaei7veJ9NfqaK95UUmnRIvFXFsRJ8LMyV4qFVTO3cTHDdegoce+SFTHdY6bQOxkOYUpKit+R7DO/D4fViLxeL1BdN6MwDQANaSw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=xXm5VJ0g; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="xXm5VJ0g" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=MS+svJjwX+WERXmMYEnQYyI5Mc94faKy2CdWQtmAb8o=; b=xXm5VJ0gzjFo5FI6ifJNt2lYYB9fpiEFwKvKrblrK5cZ5X5QR0VEIsC4iprJlRC3urHXpb75e XRqctvGI7uS/yew73xY6QXp4G2a2n8T+yKdd4nuZDj5kccyoaXIEo3Ic4MOgmKWA5NZ5J2KJg3p VaGi5GtRXJK44kah7P/dE2Q= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4gTTV230jdzcb11; Mon, 1 Jun 2026 17:40:42 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 208C040538; Mon, 1 Jun 2026 17:48:38 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:34 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 01/23] riscv: kexec_file: Fix crashk_low_res not exclude bug Date: Mon, 1 Jun 2026 17:47:43 +0800 Message-ID: <20260601094805.2928614-2-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=3DX") and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for crashkres_low.") for arm64, while implementing crashkernel=3DX,[high,low], riscv should have excluded the "crashk_low_res" reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, and the exclusion would need an extra crash_mem range. Just simply tested on qemu with crashkernel=3D4G with kexec in [1] mentioned in [2]. And the second kernel can be started normally. # dmesg | grep crash [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (= 128 MB) [ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe000= 00 (4096 MB) Cc: Guo Ren Cc: Baoquan He [1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 [2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huaw= ei.com/ Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=3DX,[high,low]") Reviewed-by: Guo Ren Signed-off-by: Jinjie Ruan --- arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/mac= hine_kexec_file.c index 54e2d9552e93..3f7766057cac 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long= *sz) unsigned int nr_ranges; int ret; =20 - nr_ranges =3D 1; /* For exclusion of crashkernel region */ + nr_ranges =3D 2; /* For exclusion of crashkernel region */ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); =20 cmem =3D kmalloc_flex(*cmem, ranges, nr_ranges); @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned lon= g *sz) =20 /* Exclude crashkernel region */ ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); - if (!ret) - ret =3D crash_prepare_elf64_headers(cmem, true, addr, sz); + if (ret) + goto out; + + if (crashk_low_res.end) { + ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); + if (ret) + goto out; + } + + ret =3D crash_prepare_elf64_headers(cmem, true, addr, sz); =20 out: kfree(cmem); --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DC37396590; Mon, 1 Jun 2026 09:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307333; cv=none; b=cJAsqBRRSnoRjehMfame9HaEBYe4pZy3KFqqs6ZBxxzSdEFLpFhA9ccgnx8rrUPhUoxozUbqYLP7dnFGs3MdAfLEeX/7w8k6bbAStwZ/Tq4OYOJ5UCVnPrJQiAL/cRWj0SiRwzM4Mfcs2GfE39ziImDjaJuuvfyt2YfRUXDtIM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307333; c=relaxed/simple; bh=4JrklAuaL71xs8Fh7DT8STuKEGBgW1Q8EtKabMapkzA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aOduNjvHnBdNYVUPtpdRluFMnTRPiUEStFMhad9djXeuVTAOtYi5FC2zgQYeJ+14VgbKZ5MfTFx4av3oNz5AASQ7jon5rqqsL3yoc+vLUNvpTr4e+trywp5iInyDEH1ytxcVtCJ++m5O8vEAD5abhThg6mx5q4iywG4yra4PWAw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=0MGx/T1E; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="0MGx/T1E" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=+4ILLVBcCmgg2fmuluXGQIe+Wa8wvQwZl0q7wZ0b1wA=; b=0MGx/T1EiFcOPTEH6lF1r992tIy/Q8e3PhaNOPVs5akFPcfXgZZ6oaexT4tzvH4ZpP20dlPf9 KVcFbe/8vDwYApyATtOgB5vKBU16tI0ouoHUG/USqZ07jxw5xL2PErsfNCNc1oomEwZaMLb35ce K6f4ZiCeAlhnlGSH+5OhQ6U= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVF4h5dzLlyD; Mon, 1 Jun 2026 17:40:53 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 0197D40562; Mon, 1 Jun 2026 17:48:42 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:38 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 02/23] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() Date: Mon, 1 Jun 2026 17:47:44 +0800 Message-ID: <20260601094805.2928614-3-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" In get_crash_memory_ranges(), if crash_exclude_mem_range() failed after realloc_mem_ranges() has successfully allocated the cmem memory, it just returns an error but leaves cmem pointing to the allocated memory, nor is it freed in the caller update_crash_elfcorehdr(), which cause a memory leak, goto out to free the cmem. Cc: Sourabh Jain Cc: Hari Bathini Cc: Michael Ellerman Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Sourabh Jain Signed-off-by: Jinjie Ruan --- arch/powerpc/kexec/crash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c index e6539f213b3d..a520f851c3a6 100644 --- a/arch/powerpc/kexec/crash.c +++ b/arch/powerpc/kexec/crash.c @@ -502,7 +502,7 @@ static void update_crash_elfcorehdr(struct kimage *imag= e, struct memory_notify * ret =3D get_crash_memory_ranges(&cmem); if (ret) { pr_err("Failed to get crash mem range\n"); - return; + goto out; } =20 /* --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E5A5399377; Mon, 1 Jun 2026 09:48:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307343; cv=none; b=WK0+2UfQlnsC4I87afOw9EVftrAC+YVz5avGqaiI+r31J1sr+wuSUdScyh5yBIULo44bZqW7WR7mk7yIpP7YoFUDnr8g6fVEhyKFf5KaGEJRr6CKpfMPvDKH/mkOWAFhcTHdu8M2oem/jvyfjALI9+lyiveV3gj5+bTzDiPfrnA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307343; c=relaxed/simple; bh=woXlGWieJalGqSw6QQi+xOgOx9A94sAzqf4CS1duDU8=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gg1UW2UxFZQpfAYiec+XSj3syT09hqJ8KjnYDFVS2dfKFv3SilN3cFFGYNIFAKrLzz2nc8ObJI8/xMMXf6DrdXwsAMtqkUzuJxKM765QnPAx6+dl245luNEDK0P1QmeN098VKRiqNPTttiDIXCdxZj0LpAMHPlWGur2qVoCJICM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=6KPOa2av; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="6KPOa2av" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=4eT52ydG2t54NS/b5dXPgA7jwihQzEhqa1y7/Wo7/ig=; b=6KPOa2avTUx1m2s1M1NqpwzXyvocvApJn4LiFv0Fj9rEPMgVobIxbK7O1QwldATXBoob5fmmd 8dmxCFHqe5YvdPmuS6cpdFMFC6WcjElx/b56lcNYqMuGSoWq16uU6xAHPAZcffBCM8/T3UjgXFo n8DkXNneauhrog+mHvXzWT4= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gTTV90cdgz12LGX; Mon, 1 Jun 2026 17:40:49 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id E5B004048F; Mon, 1 Jun 2026 17:48:45 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:41 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 03/23] powerpc/kexec_file: Fix NULL pointer dereference in kexec_extra_fdt_size_ppc64() Date: Mon, 1 Jun 2026 17:47:45 +0800 Message-ID: <20260601094805.2928614-4-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). When get_reserved_memory_ranges() successfully returns 0 on platforms without any reserved memory regions, the allocated 'rmem' pointer remains NULL. Passing this unallocated pointer directly to kexec_extra_fdt_size_ppc64() leads to a kernel panic when evaluating 'rmem->nr_ranges'. Fix this by adding a defensive NULL pointer check at the beginning of kexec_extra_fdt_size_ppc64(), returning 0 extra space immediately if no reserved memory structure exists. Cc: Sourabh Jain Cc: Hari Bathini Cc: Michael Ellerman Cc: stable@vger.kernel.org Fixes: 0d3ff067331e ("powerpc/kexec_file: fix extra size calculation for ke= xec FDT") Signed-off-by: Jinjie Ruan --- arch/powerpc/kexec/file_load_64.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_lo= ad_64.c index 8c72e12ea44e..fdeedf102c38 100644 --- a/arch/powerpc/kexec/file_load_64.c +++ b/arch/powerpc/kexec/file_load_64.c @@ -649,6 +649,9 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage *= image, struct crash_mem * struct device_node *dn; unsigned int cpu_nodes =3D 0, extra_size =3D 0; =20 + if (!rmem) + return 0; + // Budget some space for the password blob. There's already extra space // for the key name if (plpks_is_available()) --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65AB639479B; Mon, 1 Jun 2026 09:48:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307344; cv=none; b=TkP1AbbDC9lsLSsYJvUtVRQSXoq20UsBdzmHN7UYr/tJWuU0sPqi9hu+gSWP0ZsiR1KlsIjbqwhs3f6HMwDOhmmLOokHoGLh73Vp18A1w3zbX8DYjcwevfjzQ0RdaAGDQ4QEIvflKInMH36CMANpftT2KDhwZzVIerKAVNSjCZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307344; c=relaxed/simple; bh=yJZ9iOSp3GWLKvGwAskw3D37iCzIq/W56v0sFt176Ys=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CTvhj0248W7mCDC+je1r16Vz3br+Fm1L40Kf/9wZ2xJG1OLPI0U29G9P4NTJknjY82FyohqlT7kXkCcSh5PuAapnlnfEsWJjOtR50O73vCHMCvAlcT3BtvQVO1BH5WGQlRDqY6rm2iuJQIc6IcnCkfdiCFmEECWmEuxK0ULJ19U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Fxpfysxr; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Fxpfysxr" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=8EnmU9JMCid8f25OUQXP00boV0OiTYhaVmjNgi7O15U=; b=FxpfysxrDR9Z3N/z2FzLQ1redjsb8v9bYZrgwkOLY1V7vvU9WSoFF5k9qkeJwx1wfpRWLcpVx swZvy2I8bsFWOiKD4o+W6S6rk20znDPInkJynNfB+gPu1Dd8JseMuHQSc1kNWZ6yZFBauRJxmHj 33qeJTuPJ77dl1V2na7GErY= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVD753tz12LGX; Mon, 1 Jun 2026 17:40:52 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id CDEA2201E9; Mon, 1 Jun 2026 17:48:49 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:45 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 04/23] powerpc/kexec_file: Fix memory range truncation in __merge_memory_ranges() Date: Mon, 1 Jun 2026 17:47:46 +0800 Message-ID: <20260601094805.2928614-5-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=3D0): [0x1000 - 0x9000] Range B (i=3D1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=3D2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=3D1 (Range B): ranges[1].start (0x2000) <=3D ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end =3D ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=3D2 (Range C): ranges[2].start (0x6000) <=3D ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated. Cc: Sourabh Jain Cc: Hari Bathini Cc: Michael Ellerman Cc: stable@vger.kernel.org Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for getting = memory ranges") Signed-off-by: Jinjie Ruan --- arch/powerpc/kexec/ranges.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c index 867135560e5c..eb45e89502ca 100644 --- a/arch/powerpc/kexec/ranges.c +++ b/arch/powerpc/kexec/ranges.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -105,19 +106,16 @@ static void __merge_memory_ranges(struct crash_mem *m= em_rngs) struct range *ranges; int i, idx; =20 - if (!mem_rngs) + if (!mem_rngs || mem_rngs->nr_ranges <=3D 1) return; =20 idx =3D 0; - ranges =3D &(mem_rngs->ranges[0]); + ranges =3D mem_rngs->ranges; for (i =3D 1; i < mem_rngs->nr_ranges; i++) { - if (ranges[i].start <=3D (ranges[i-1].end + 1)) - ranges[idx].end =3D ranges[i].end; + if (ranges[i].start <=3D (ranges[idx].end + 1)) + ranges[idx].end =3D max(ranges[idx].end, ranges[i].end); else { idx++; - if (i =3D=3D idx) - continue; - ranges[idx] =3D ranges[i]; } } --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A034396D03; Mon, 1 Jun 2026 09:49:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307350; cv=none; b=ShXEEqC+6VMxPrN0aPsMM/w5/8K7XeZEufPsYF5x/nOXdCSC4Zjq3auUjPsGEpz4DBpvwaeq7qGPor2yMgqbAtaDnYnk6RPOxqEVBcm7bu8L+XP1gEUzW947kXsfNk5/QwpIWUrJPnJ0xALpsUbu/0SRcrtNfq8GMJyTEo+AHLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307350; c=relaxed/simple; bh=Exmh6s7DbZm7DfwGbfrT4EM0TPc/Tf5FsQ/Pr51c6k8=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N6ClxQwT5KkxWW/KC9m6efM1oycN+uIWlF/n6yOwVW8GA3wdIn2K3lq4WLWW2cg2PJY+qJeaHWThOdRc3u0e6iPM8vrTceKhPy6KuoNOFqEmHUYddRXRyrPBxnwvFGlKiZThmrMUxp/8L8AxhI4s/RlawddfsWBfoyYghFw4qU4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=LSORrdH1; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="LSORrdH1" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=dtc4/NrtG2M2/NTu9Dfj4w1EdTwFqK3w2EGmJt3YJfk=; b=LSORrdH1lNoFWXXQS9gOPZ3GNVa3ecvXGMA9ld+M6rLgHx2sr5j7Fq2G0Wi2rHMgU+0UGbsOM dS8uEqVPnjdLyyFxwclLxewkwC9sqLElnsjtJmnFBkcp9voEWnKOmHq5Vy30shiuwvA3BSKUFr0 oyz/nZ4BOYaUsS8XJXrrKsw= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVQ4JpJz1prM3; Mon, 1 Jun 2026 17:41:02 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id CD07140561; Mon, 1 Jun 2026 17:48:53 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:49 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 05/23] powerpc/crash: sort crash memory ranges before preparing elfcorehdr Date: Mon, 1 Jun 2026 17:47:47 +0800 Message-ID: <20260601094805.2928614-6-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" From: Sourabh Jain During a memory hot-remove event, the elfcorehdr is rebuilt to exclude the removed memory. While updating the crash memory ranges for this operation, the crash memory ranges array can become unsorted. This happens because remove_mem_range() may split a memory range into two parts and append the higher-address part as a separate range at the end of the array. So far, no issues have been observed due to the unsorted crash memory ranges. However, this could lead to problems once crash memory range removal is handled by generic code, as introduced in the upcoming patches in this series. Currently, powerpc uses a platform-specific function, remove_mem_range(), to exclude hot-removed memory from the crash memory ranges. This function performs the same task as the generic crash_exclude_mem_range() in crash_core.c. The generic helper also ensures that the crash memory ranges remain sorted. So remove the redundant powerpc-specific implementation and instead call crash_exclude_mem_range_guarded() (which internally calls crash_exclude_mem_range()) to exclude the hot-removed memory ranges. Cc: Andrew Morton Cc: Baoquan he Cc: Jinjie Ruan Cc: Hari Bathini Cc: Madhavan Srinivasan Cc: Mahesh Salgaonkar Cc: Michael Ellerman Cc: Ritesh Harjani (IBM) Cc: Shivang Upadhyay Cc: linux-kernel@vger.kernel.org Acked-by: Baoquan He Reviewed-by: Ritesh Harjani (IBM) Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Sourabh Jain Signed-off-by: Jinjie Ruan --- arch/powerpc/include/asm/kexec_ranges.h | 4 +- arch/powerpc/kexec/crash.c | 5 +- arch/powerpc/kexec/ranges.c | 87 +------------------------ 3 files changed, 7 insertions(+), 89 deletions(-) diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include= /asm/kexec_ranges.h index 14055896cbcb..ad95e3792d10 100644 --- a/arch/powerpc/include/asm/kexec_ranges.h +++ b/arch/powerpc/include/asm/kexec_ranges.h @@ -7,7 +7,9 @@ void sort_memory_ranges(struct crash_mem *mrngs, bool merge); struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges); int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size); -int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size); +int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges, + unsigned long long mstart, + unsigned long long mend); int get_exclude_memory_ranges(struct crash_mem **mem_ranges); int get_reserved_memory_ranges(struct crash_mem **mem_ranges); int get_crash_memory_ranges(struct crash_mem **mem_ranges); diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c index a520f851c3a6..d634db67becc 100644 --- a/arch/powerpc/kexec/crash.c +++ b/arch/powerpc/kexec/crash.c @@ -493,7 +493,7 @@ static void update_crash_elfcorehdr(struct kimage *imag= e, struct memory_notify * struct crash_mem *cmem =3D NULL; struct kexec_segment *ksegment; void *ptr, *mem, *elfbuf =3D NULL; - unsigned long elfsz, memsz, base_addr, size; + unsigned long elfsz, memsz, base_addr, size, end; =20 ksegment =3D &image->segment[image->elfcorehdr_index]; mem =3D (void *) ksegment->mem; @@ -512,7 +512,8 @@ static void update_crash_elfcorehdr(struct kimage *imag= e, struct memory_notify * if (image->hp_action =3D=3D KEXEC_CRASH_HP_REMOVE_MEMORY) { base_addr =3D PFN_PHYS(mn->start_pfn); size =3D mn->nr_pages * PAGE_SIZE; - ret =3D remove_mem_range(&cmem, base_addr, size); + end =3D base_addr + size - 1; + ret =3D crash_exclude_mem_range_guarded(&cmem, base_addr, end); if (ret) { pr_err("Failed to remove hot-unplugged memory from crash memory ranges\= n"); goto out; diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c index eb45e89502ca..b2fb78562cdc 100644 --- a/arch/powerpc/kexec/ranges.c +++ b/arch/powerpc/kexec/ranges.c @@ -551,7 +551,7 @@ int get_usable_memory_ranges(struct crash_mem **mem_ran= ges) #endif /* CONFIG_KEXEC_FILE */ =20 #ifdef CONFIG_CRASH_DUMP -static int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges, +int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges, unsigned long long mstart, unsigned long long mend) { @@ -639,89 +639,4 @@ int get_crash_memory_ranges(struct crash_mem **mem_ran= ges) pr_err("Failed to setup crash memory ranges\n"); return ret; } - -/** - * remove_mem_range - Removes the given memory range from the range list. - * @mem_ranges: Range list to remove the memory range to. - * @base: Base address of the range to remove. - * @size: Size of the memory range to remove. - * - * (Re)allocates memory, if needed. - * - * Returns 0 on success, negative errno on error. - */ -int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size) -{ - u64 end; - int ret =3D 0; - unsigned int i; - u64 mstart, mend; - struct crash_mem *mem_rngs =3D *mem_ranges; - - if (!size) - return 0; - - /* - * Memory range are stored as start and end address, use - * the same format to do remove operation. - */ - end =3D base + size - 1; - - for (i =3D 0; i < mem_rngs->nr_ranges; i++) { - mstart =3D mem_rngs->ranges[i].start; - mend =3D mem_rngs->ranges[i].end; - - /* - * Memory range to remove is not part of this range entry - * in the memory range list - */ - if (!(base >=3D mstart && end <=3D mend)) - continue; - - /* - * Memory range to remove is equivalent to this entry in the - * memory range list. Remove the range entry from the list. - */ - if (base =3D=3D mstart && end =3D=3D mend) { - for (; i < mem_rngs->nr_ranges - 1; i++) { - mem_rngs->ranges[i].start =3D mem_rngs->ranges[i+1].start; - mem_rngs->ranges[i].end =3D mem_rngs->ranges[i+1].end; - } - mem_rngs->nr_ranges--; - goto out; - } - /* - * Start address of the memory range to remove and the - * current memory range entry in the list is same. Just - * move the start address of the current memory range - * entry in the list to end + 1. - */ - else if (base =3D=3D mstart) { - mem_rngs->ranges[i].start =3D end + 1; - goto out; - } - /* - * End address of the memory range to remove and the - * current memory range entry in the list is same. - * Just move the end address of the current memory - * range entry in the list to base - 1. - */ - else if (end =3D=3D mend) { - mem_rngs->ranges[i].end =3D base - 1; - goto out; - } - /* - * Memory range to remove is not at the edge of current - * memory range entry. Split the current memory entry into - * two half. - */ - else { - size =3D mem_rngs->ranges[i].end - end + 1; - mem_rngs->ranges[i].end =3D base - 1; - ret =3D add_mem_range(mem_ranges, end + 1, size); - } - } -out: - return ret; -} #endif /* CONFIG_CRASH_DUMP */ --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B00C3988F8; Mon, 1 Jun 2026 09:49:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307347; cv=none; b=iPpMuPGuGBHKIcCouSYxXexHK9gZ2ZXkcr3Dv50HRDo8idqML41K3Tn6uOJjCTGO2GjiNR4SATZTo7wyNs3itgOosroN1tC9S9M7ejqX7Yyl5WwoQ+SrqIGaPt7vF77f9bsMeQ4IsAH4batKf05bJDg4EODmffBLuIv86FkiEeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307347; c=relaxed/simple; bh=4ajyKOULOx3xqzSlBVev+IgSyIEw3vgjkeUZJEp6aiQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pysa0ky9bv/7YOMkBZ4mZNC6gJDOuV0nCStAtT7LWP5zlnmcWEMXTSHAcEAsXumc9nfW99EaYvSo8OxzqfC/dWiIFhyGjA8CE1HI/ULYZ5GxsmwGII1mAZoHb1xkChVPFu3eFQSRsYkXfGb87UJPCX8cntxbwssCof0mOG5YztU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=MP/a67Lp; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="MP/a67Lp" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=FoTEQM/LHeMQktZIXiOh72cymJcqDmq0T6smro86PHs=; b=MP/a67LplmOvMEmzF3qOent0LLi5OYYNL1s93hEe9QYI7yu5Jz6/lbnpd46Gp8VzrkTtl5xL6 vHjF/YT0QhU/knfEZRlmG4hUtG590RYYLpqwIB5HGbsdbiPp/AdeGF+aZYEJpysjcRwsMaYBX8o edIQvxdYlCHGBMJuccpHPJc= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVQ02Lzzcb1n; Mon, 1 Jun 2026 17:41:02 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id B0AFE40538; Mon, 1 Jun 2026 17:48:57 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:53 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 06/23] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Date: Mon, 1 Jun 2026 17:47:48 +0800 Message-ID: <20260601094805.2928614-7-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" The generic kimage_free_cma() relies on `image->nr_segments` to iterate and free allocated CMA pages. However, during architecture-specific segment placement retry loops (e.g., arm64's image_load()), a mid-way failure will truncate `image->nr_segments` back to its initial value. This truncation permanently hides any CMA pages allocated outside the new boundary from global cleanup, causing silent background memory leaks. To allow architecture-specific loaders to execute fine-grained memory reclamation before truncation occurs, extract the single-pass CMA release logic into a dedicated and exported helper: void kexec_free_segment_cma(struct kimage *image, unsigned long idx); Refactor the main kimage_free_cma() to invoke this helper sequentially to maintain backward compatibility while expanding single-slot flexibility. Signed-off-by: Jinjie Ruan --- include/linux/kexec.h | 2 ++ kernel/kexec_core.c | 25 ++++++++++++++----------- 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 8a22bc9b8c6c..6f1eabda0300 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -532,6 +532,7 @@ extern bool kexec_file_dbg_print; =20 extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); +extern void kexec_free_segment_cma(struct kimage *image, unsigned long idx= ); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; struct task_struct; @@ -543,6 +544,7 @@ static inline int kexec_crash_loaded(void) { return 0; } static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } +static inline void kexec_free_segment_cma(struct kimage *image, unsigned l= ong idx) { } #define kexec_in_progress false #endif /* CONFIG_KEXEC_CORE */ =20 diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index a43d2da0fe3e..9195f81e53c4 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -554,22 +554,25 @@ static void kimage_free_entry(kimage_entry_t entry) kimage_free_pages(page); } =20 -static void kimage_free_cma(struct kimage *image) +void kexec_free_segment_cma(struct kimage *image, unsigned long idx) { - unsigned long i; + u32 nr_pages =3D image->segment[idx].memsz >> PAGE_SHIFT; + struct page *cma =3D image->segment_cma[idx]; =20 - for (i =3D 0; i < image->nr_segments; i++) { - struct page *cma =3D image->segment_cma[i]; - u32 nr_pages =3D image->segment[i].memsz >> PAGE_SHIFT; + if (!cma) + return; =20 - if (!cma) - continue; + arch_kexec_pre_free_pages(page_address(cma), nr_pages); + dma_release_from_contiguous(NULL, cma, nr_pages); + image->segment_cma[idx] =3D NULL; +} =20 - arch_kexec_pre_free_pages(page_address(cma), nr_pages); - dma_release_from_contiguous(NULL, cma, nr_pages); - image->segment_cma[i] =3D NULL; - } +static void kimage_free_cma(struct kimage *image) +{ + unsigned long i; =20 + for (i =3D 0; i < image->nr_segments; i++) + kexec_free_segment_cma(image, i); } =20 void kimage_free(struct kimage *image) --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E3B323A168E; Mon, 1 Jun 2026 09:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307354; cv=none; b=ep/if9saldtd+ug569MR5xZeLumqsdpM6zsYvfe4FndnyBFhE3eD9jxwdR4w9rJj36U/0NschEleo9ZfizD7lGRoVCxxAi6zIUKoyH2mT7+tHnMYv3D7WdiaLJwUOsVD146u2XgSrdl3cJMRJBUIcZc2mwOnhgRTfoZIFRSI3nc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307354; c=relaxed/simple; bh=bIqV+PNc20SuCoalckU2ml8nlwSbZP821FBY2KdPR9E=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dcB9lDuYbu4zrLB2s56UW3Cwdf+m7DlUCi85TDbqrbsVXqzdyxCcdcVd2dmALDAkATtGrv33PDjAHF9wAp8IYGNzpd+27xDYYU4S2vpUhDVQkxXPsxIkh6HwmTM3hcl0sNqsGlXnhhOv7aG491ky+yla8t1srtRmp+uq1FSI3FM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=K+9Cpzom; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="K+9Cpzom" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=3CM+Au3SXosW29XrHZBLTzStvKPXPYXLJ81pyBZwyQo=; b=K+9Cpzombw+R1hz+4oTY8H0FgupdRElbxcNkGJexiHXFS/yuEYiEV0xUzMPD0jBtDpTNTrOUd 5pjSAy+NXj9LNHESyhBYSfroq164Dq/6YwKWnvf9H9/9K0QFK3HcM9jHW3afdFVuVnBCUGVg5Sa pJKFnhLybZVSXQuwmunxwx0= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVd1hx6zRhQr; Mon, 1 Jun 2026 17:41:13 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 98392201E9; Mon, 1 Jun 2026 17:49:01 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:48:57 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 07/23] arm64: kexec_file: Fix CMA page leaks during segment placement retry loops Date: Mon, 1 Jun 2026 17:47:49 +0800 Message-ID: <20260601094805.2928614-8-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out, during arm64 kexec image placement retry loops in image_load(), the loader repeatedly attempts to find a suitable memory hole for the kernel and its associated segments (initrd, dtb, etc.). When a placement attempt fails midway, the core framework rolls back `image->nr_segments` to its initial state to purge the failed segments logically. However, this truncation causes a severe background memory leak. Any CMA pages successfully allocated via kexec_add_buffer() during the failed attempt are recorded in the `image->segment_cma` array. Since the subsequent global kimage_free_cma() cleanup only iterates up to the truncated (smaller) `nr_segments` boundary, these allocated CMA pages outside the new boundary become completely orphaned and permanently leaked. Fix this by leverage the newly introduced generic kexec_free_segment_cma() helper to execute fine-grained memory reclamation before any truncation occurs: 1. In image_load(), explicitly invoke kexec_free_segment_cma() to release the CMA buffer allocated for the current failed kernel segment before decrementing `image->nr_segments`. 2. In the error path of load_other_segments(), iterate backward from the failed segment index down to `orig_segments`, sequentially freeing each orphan CMA segment allocation before restoring the initial segment count. This guarantees that all temporary CMA pages allocated during placement failures are cleanly returned to the contiguous memory allocator, eliminating silent background memory leaks across all retry paths. Cc: Catalin Marinas Cc: Will Deacon Cc: Breno Leitao Cc: Pratyush Yadav Cc: Andrew Morton Cc: Yeoreum Yun Cc: Kees Cook Cc: "Rob Herring (Arm)" Cc: Baoquan He Cc: Coiby Xu Cc: Alexander Graf Cc: Pasha Tatashin Cc: stable@vger.kernel.org Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation") Signed-off-by: Jinjie Ruan --- 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_imag= e.c index b70f4df15a1a..ffcb7f9075e6 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 -=3D 1; kbuf.buf_min =3D kernel_segment->mem + kernel_segment->memsz; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index e31fabed378a..13c247c28866 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -195,7 +195,10 @@ int load_other_segments(struct kimage *image, return 0; =20 out_err: - image->nr_segments =3D orig_segments; + while (image->nr_segments > orig_segments) { + kexec_free_segment_cma(image, image->nr_segments - 1); + image->nr_segments--; + } kvfree(dtb); return ret; } --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 448A83A2E0A; Mon, 1 Jun 2026 09:49:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307357; cv=none; b=dlKwwRmjA1xPbYLGfe+VIsphs7AWQsRoMj2llicCvzrUF1/g3dTY1tzvBiWvzrMaIY7z7sq0dpmaArwDOZSqOpEvfbNcdxq99aEDDNM3wuNUo6pzKpJPqar/adhBPk6hle/Rnzfi5jZSMbBJtn4DuEMjjWqdUePNTr+0TA62ktE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307357; c=relaxed/simple; bh=VWCh764KJgES0hT94BkYDXmG3lrejV2+7Q8fMSyyJLM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nbyl93KBqm34fW0Gm0DO2O1rbn/7UQLaDrN6gPlJ0T2UQ6lD4Q5oiogy7BQxT55xXo7pow36DdhcmhrGTMPmsPUxCdXPR8d09Xf3vXu3lGOYLj9SY1zc8/CMF/vdO4Dx1Jxzarfcb0p64iOOtbgMfYwL2b/T0tqnROxySn9dBDg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=bFXrEAmx; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="bFXrEAmx" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=mhbjseTwLH5bkq29znj9WodUduQsJ+dnwL0KiZfm0D0=; b=bFXrEAmxNUF6FjQBgDHXLvQgRz1WzTvJpan8xYXPMuWfugdqx4Wk0Iq4YlyEzum2/zn00Si80 OoGDUvHH6r0WlRCzADhKozhdYN/ZsA3n/2DN5UKl/Z8ZltJVBpyZZVb/hA66rwLSaJ7innpLd3l iqivnTTAbyDpUGrGO3E1rrc= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVf21jPz1prLw; Mon, 1 Jun 2026 17:41:14 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 86E714048F; Mon, 1 Jun 2026 17:49:05 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:01 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 08/23] arm64: kexec_file: Fix image->elf_headers memory leak during retry loop Date: Mon, 1 Jun 2026 17:47:50 +0800 Message-ID: <20260601094805.2928614-9-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out a potential memory leak of image->elf_headers when load_other_segments() fails on error paths. In the arm64 kexec_file file-load path, kexec_image.c runs a retry loop calling kexec_add_buffer() to find a suitable location for the kernel segment. On each iteration, load_other_segments() is invoked to allocate and populate alternative segments such as initrd, DTB, and ELF headers. However, if a placement or allocation failure occurs later in load_other_segments() (e.g., when adding initrd or dtb), the execution jumps to the out_err label. While this path restores image->nr_segments via orig_segments, it returns an error back to the caller without freeing the previously allocated image->elf_headers vmalloc buffer. As a result, the retry loop in image_load() unconditionally allocates new ELF headers on the next iteration and overwrites image->elf_headers, permanently leaking the memory blocks allocated in previous iterations. To fix this, decouple the ELF header allocation from the target-seeking retry loop. Since the contents and size of ELF headers only depend on the host memory layout and do not change with the kernel's physical placement, move prepare_elf_headers() completely outside and prior to the while retry loop in image_load(). And if kexec_add_buffer() for elf headers fails, not need to vfree headers, because the err path will vfree `image->elf_headers` by calling arch_kimage_file_post_load_cleanup(). This optimization eliminates redundant memory allocation/deallocation overhead during kexec placement retries and eradicates the Use-After-Free and memory leak risk. Concurrently, remove the prepare_elf_headers() call from inside load_other_segments() and have it directly reuse the single, pre-allocated image->elf_headers. Cc: Catalin Marinas Cc: Will Deacon Cc: Thomas Huth Cc: Breno Leitao Cc: Andrew Morton Cc: Yeoreum Yun Cc: Coiby Xu Cc: Baoquan He Cc: Kees Cook Cc: Benjamin Gwin Cc: stable@vger.kernel.org Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segmen= ts fails") Signed-off-by: Jinjie Ruan --- v15: - Use image->elf_headers and image->elf_headers_sz instead of adding functi= on parameters for load_other_segments() to simplify the fix. --- arch/arm64/include/asm/kexec.h | 1 + arch/arm64/kernel/kexec_image.c | 16 ++++++++++++++++ arch/arm64/kernel/machine_kexec_file.c | 23 +++++------------------ 3 files changed, 22 insertions(+), 18 deletions(-) diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h index 892e5bebda95..7ffa2ff5fcfd 100644 --- a/arch/arm64/include/asm/kexec.h +++ b/arch/arm64/include/asm/kexec.h @@ -128,6 +128,7 @@ extern int load_other_segments(struct kimage *image, unsigned long kernel_load_addr, unsigned long kernel_size, char *initrd, unsigned long initrd_len, char *cmdline); +extern int prepare_elf_headers(void **addr, unsigned long *sz); #endif =20 #endif /* __ASSEMBLER__ */ diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_imag= e.c index ffcb7f9075e6..424b9527db09 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -89,6 +89,22 @@ static void *image_load(struct kimage *image, =20 kernel_segment_number =3D image->nr_segments; =20 +#ifdef CONFIG_CRASH_DUMP + if (image->type =3D=3D KEXEC_TYPE_CRASH) { + /* load elf core header */ + unsigned long headers_sz; + void *headers; + + ret =3D prepare_elf_headers(&headers, &headers_sz); + if (ret) { + pr_err("Preparing elf core header failed\n"); + return ERR_PTR(ret); + } + image->elf_headers =3D headers; + image->elf_headers_sz =3D headers_sz; + } +#endif + /* * The location of the kernel segment may make it impossible to satisfy * the other segment requirements, so we try repeatedly to find a diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index 13c247c28866..4cbb71e1f8ed 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -40,7 +40,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage *ima= ge) } =20 #ifdef CONFIG_CRASH_DUMP -static int prepare_elf_headers(void **addr, unsigned long *sz) +int prepare_elf_headers(void **addr, unsigned long *sz) { struct crash_mem *cmem; unsigned int nr_ranges; @@ -105,32 +105,19 @@ int load_other_segments(struct kimage *image, kbuf.buf_min =3D kernel_load_addr + kernel_size; =20 #ifdef CONFIG_CRASH_DUMP - /* load elf core header */ - void *headers; - unsigned long headers_sz; if (image->type =3D=3D KEXEC_TYPE_CRASH) { - ret =3D prepare_elf_headers(&headers, &headers_sz); - if (ret) { - pr_err("Preparing elf core header failed\n"); - goto out_err; - } - - kbuf.buffer =3D headers; - kbuf.bufsz =3D headers_sz; + kbuf.buffer =3D image->elf_headers; + kbuf.bufsz =3D image->elf_headers_sz; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; - kbuf.memsz =3D headers_sz; + kbuf.memsz =3D image->elf_headers_sz; kbuf.buf_align =3D SZ_64K; /* largest supported page size */ kbuf.buf_max =3D ULONG_MAX; kbuf.top_down =3D true; =20 ret =3D kexec_add_buffer(&kbuf); - if (ret) { - vfree(headers); + if (ret) goto out_err; - } - image->elf_headers =3D headers; image->elf_load_addr =3D kbuf.mem; - image->elf_headers_sz =3D headers_sz; =20 kexec_dprintk("Loaded elf core header at 0x%lx bufsz=3D0x%lx memsz=3D0x%= lx\n", image->elf_load_addr, kbuf.bufsz, kbuf.memsz); --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4985238AC99; Mon, 1 Jun 2026 09:49:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307361; cv=none; b=UDcR7RWL/KIo3niSrEQkpihLiY+rUEbM5Drj8+YvNUHcKkbkjtdU0tkctka+QGmt1Rvv3hKYoCZsG1uLZMtmMumFs0n43hpIr+9VLtZ6tTeir3uJ008xwrhr/r+wn8UvS6BjKUXSDUnfQMLnBQ43CLczCkSdo17SMg27qnKIA3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307361; c=relaxed/simple; bh=bDBGw+/44lWMAbskVKorFLnBHGTb3IX2ml5xfQQk7n0=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=e5b0FgyKLucD3N83xIDxIElC1jYDqn/EFJoeJNyOq/qZOVUZuZS/M/uq3+asuu6JJvmQLaUwWHUhHQDx4UGTqAn7Pptd4Ei3r6qDF2ZmgI6TF98fY1uYwhKERsz9nemHBI2jROw0ajOadCWny8TU/cnrTnctpdoNbgAXDegUOdc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=CGyYVbD7; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="CGyYVbD7" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=KOHJL6mB3QG5vHKM18gpTSqf5pouid7XPpWu+feKDDU=; b=CGyYVbD74f6ojvlQ2RjjD+G63/AYVfLUPyObucsAa1qv1wH5L6x6HyV1k861pqznz+0ZdBfVH cEgjV9n20kMLCmaxIM24r48pPiCMvW1SmTf5FnuwY25bpdgeKC3N+uylR+JeqvJVYmccZSBBmGU tnuZ1w/PVmvl1SLSIysESLM= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVc4GQwz12LGX; Mon, 1 Jun 2026 17:41:12 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 6B822201E9; Mon, 1 Jun 2026 17:49:09 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:05 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 09/23] kexec: Fix UAF and Double Free in crash_load_dm_crypt_keys() Date: Mon, 1 Jun 2026 17:47:51 +0800 Message-ID: <20260601094805.2928614-10-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" A static memory safety review by Sashiko AI identified a high-severity Use-After-Free (UAF) and Double Free vulnerability in the dm-crypt keys handling path during arm64 kexec image placement retry loops. In crash_load_dm_crypt_keys(), when the segment allocation fails via kexec_add_buffer(), the error path invokes `kvfree((void *)kbuf.buffer)` to reclaim the keys buffer. However, the global pointer `keys_header` is left dangling with a stale address, creating an insecure memory trap. When the top-level loader image_load() retries the next available placement hole, crash_load_dm_crypt_keys() is re-entered. Since `is_dm_key_reused` is a read-only global configuration managed by user-space configfs, it cannot be mutated by the kernel. If it remains true, the loader skips build_keys_header() and blindly reuses the stale `keys_header` pointer for kbuf.buffer, triggering a severe Use-After-Free or a Null pointer dereference during kexec_add_buffer(). Alternatively, a new headers build can trigger a recursive Double Free inside build_keys_header(). Fix this by setting the global `keys_header` to NULL immediately after it is freed in the failure path. Concurrently, upgrade the header regeneration check to a composite condition: `if (!is_dm_key_reused || !keys_header)` This ensures that if a previous retry attempt wiped the buffer, the kernel will automatically and safely trigger a fresh header regeneration internally without modifying the user-configured `is_dm_key_reused` state flag, achieving absolute data consistency and memory safety across all retry paths. Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: Pasha Tatashin Cc: Pratyush Yadav Cc: Dave Young Cc: stable@vger.kernel.org Fixes: e3a84be1ec2f ("arm64,ppc64le/kdump: pass dm-crypt keys to kdump kern= el") Signed-off-by: Jinjie Ruan --- kernel/crash_dump_dm_crypt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c index cb875ddb6ba6..2c5462876337 100644 --- a/kernel/crash_dump_dm_crypt.c +++ b/kernel/crash_dump_dm_crypt.c @@ -412,13 +412,12 @@ int crash_load_dm_crypt_keys(struct kimage *image) }; int r; =20 - if (key_count <=3D 0) { kexec_dprintk("No dm-crypt keys\n"); return 0; } =20 - if (!is_dm_key_reused) { + if (!is_dm_key_reused || unlikely(!keys_header)) { image->dm_crypt_keys_addr =3D 0; r =3D build_keys_header(); if (r) { @@ -437,6 +436,7 @@ int crash_load_dm_crypt_keys(struct kimage *image) if (r) { pr_err("Failed to call kexec_add_buffer, ret=3D%d\n", r); kvfree((void *)kbuf.buffer); + keys_header =3D NULL; return r; } image->dm_crypt_keys_addr =3D kbuf.mem; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3C693A5989; Mon, 1 Jun 2026 09:49:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307369; cv=none; b=ENPXHI+L/Wo1bWDKCeJkGiFsTB3SpPPflg/8WeBFbjjAvoxPN6BFmLF20gYE0MauHvxR0ugVpfu9j2V8h503bl93imlnQy1c3yCr+6YvUuZVpSAfPYVFX46rDsmJmKqv5tGbTph9oMY5K6uGcBYA1xJJbqtPZtp/tLoHwq+J7pE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307369; c=relaxed/simple; bh=fLGjiZzUwqqk2Rjy+lirz48w6trkeGSAfDwg46aO3PQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Hh+zfW7p2eWDbKY5C7kCP3SluZiWHxRPqwTbACPCJ/cq5uHsO21qoFcWplW2uETXe22Ktza2KIQ7kgdWr+G5LCy/KNlW+2qu7DZww8D0cpdUNIUFVsNvmjtfIVFnwLpf3GOpK5jGPtxJFejTTixwhluXxyH3M2NgNPjeNk5XPgs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=HGwpKv0O; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="HGwpKv0O" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=/EZ2c7x/ajxc2orWikWAwwQyMa5jAYw6SumwsI32OoA=; b=HGwpKv0O7ApKJjaW9gsuJUkkrhmpM/LvH/twujKd6Oaga2aDJrYaqhAKElmgvbL1/f5dvUiQj QuSJuPvXSHv7wARw1n2QwLSueQXjDCFmfk6PeMrwk2F9wSKSFUPtdktFv5z5XXlNLvBvFP5SxwP zMIhcXDosQjj/FFU5cUAqoo= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVq32VdzmV6x; Mon, 1 Jun 2026 17:41:23 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 57E0240539; Mon, 1 Jun 2026 17:49:13 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:09 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 10/23] crash_core: Introduce CRASH_HOTPLUG_SAFETY_PADDING for memory hotplug safety Date: Mon, 1 Jun 2026 17:47:52 +0800 Message-ID: <20260601094805.2928614-11-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Introduce CRASH_HOTPLUG_SAFETY_PADDING to allocate extra slots for the crash memory ranges array, mitigating potential TOCTOU races caused by concurrent memory hotplug events. When CONFIG_MEMORY_HOTPLUG is disabled, the padding safely defaults to 0 as the memory layout remains static. Signed-off-by: Jinjie Ruan --- include/linux/crash_core.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index c1dee3f971a9..d4762e000098 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -14,6 +14,12 @@ struct crash_mem { struct range ranges[] __counted_by(max_nr_ranges); }; =20 +#ifdef CONFIG_MEMORY_HOTPLUG +#define CRASH_HOTPLUG_SAFETY_PADDING 128 +#else +#define CRASH_HOTPLUG_SAFETY_PADDING 0 +#endif + #ifdef CONFIG_CRASH_DUMP =20 int crash_shrink_memory(unsigned long new_size); --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0D293A5439; Mon, 1 Jun 2026 09:49:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307367; cv=none; b=mXQ9DR2OwyQp1sDKzdj7D/IM1TLo6+eIRsRwWfJi3ebR4ybUuD0kseIJNT4vUQPzOuXuUODl6zHL8Os4WQ7wsyIN/GleVgYJw7CKuNe9c9Tl3fB4Er27yZSq0PTIWc6psufIC0EMQZAvlc87DxWhXzlaLiZWCQlVhcY1J+5dQNg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307367; c=relaxed/simple; bh=TgdJon7C2cFgGIlIfZtkkO6O0Nz+5MMW7+CzwYvlyPw=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=F9HLMIx5sh9nTxnCyhARaPbay/R1QH1kxIBM2nryC/fGVxArKZMpTpKGd/RwIqmVYSvcVqphY7uEcjgNkFNo0WA3Dptshx3ZUQeJ2stHIDkHOxF+B9JJvSQUdFk9BlbPcODWEdgk4rOSxpRjyGTxOI9NuaUQT+ezsKep2MAE7q4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=3i1e9DKP; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="3i1e9DKP" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=64I2BMSOSCFqQLjL6hwB7H/FbA7URWKJtLdv/hf3DNw=; b=3i1e9DKP7dDswVMCRUQrnqriT1T4r6ei7MZXwGx/X/z/KBZwgP3gbL0Ec12wICRtkfbQKFVL3 iyhdyDwYaNa1LeGTetx1lIs8SlU+SwzZLAqVzMtz9YNB+oi7oJYUc9TG5oeL85jSOXKrruGVm8Q TrQPpdRDIZTgH678BTiYDGA= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVx5Njwz1cyPT; Mon, 1 Jun 2026 17:41:29 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 424D840562; Mon, 1 Jun 2026 17:49:17 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:13 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 11/23] x86: kexec_file: Fix TOCTOU buffer overflow via memory region padding Date: Mon, 1 Jun 2026 17:47:53 +0800 Message-ID: <20260601094805.2928614-12-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out there is a TOCTOU (Time-of-Check to Time-of-Use) race condition in prepare_elf_headers() between the initial pass that counts System RAM ranges and the second pass that populates them. If a memory hotplug event occurs between these two steps, the number of memory regions may increase, causing an out-of-bounds write to the cmem->ranges[] array. Fix this fundamentally by using `CRASH_HOTPLUG_SAFETY_PADDING`(128 slots) to expand the flexible array allocation ceiling upfront. This safely absorbs any concurrent memory region expansion. Concurrently, add a defensive boundary check inside the callback to return -EAGAIN on unexpected overrun, fully eradicating the overflow window and ensuring system stability. Cc: AKASHI Takahiro Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andrew Morton Cc: Baoquan He Cc: Mike Rapoport Cc: stable@vger.kernel.org Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash= _mem buffer") Signed-off-by: Jinjie Ruan --- arch/x86/kernel/crash.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index cd796818d94d..a1089907728d 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -177,7 +177,7 @@ static struct crash_mem *fill_up_crash_elf_data(void) * But in order to lest the low 1M could be changed in the future, * (e.g. [start, 1M]), add a extra slot. */ - nr_ranges +=3D 3 + crashk_cma_cnt; + nr_ranges +=3D 3 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADDING; cmem =3D vzalloc(struct_size(cmem, ranges, nr_ranges)); if (!cmem) return NULL; @@ -226,6 +226,9 @@ static int prepare_elf64_ram_headers_callback(struct re= source *res, void *arg) { struct crash_mem *cmem =3D arg; =20 + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) + return -EAGAIN; + cmem->ranges[cmem->nr_ranges].start =3D res->start; cmem->ranges[cmem->nr_ranges].end =3D res->end; cmem->nr_ranges++; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8F493A5E77; Mon, 1 Jun 2026 09:49:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307372; cv=none; b=VOXPaUyAbWMMsdr3f0usFMYHxV/GdbW+CouaDJ5eJDxISAB2vN4btTlc/orFhmg5D8yY9Ge3Ab3q5kLPbvKQi/5Ex5OHeVq/+vCKslonfoYFsiYhx/87RwptFDi9ij01bWo84tMafnG49vSjfC/bvVtBLv+gZN0nrWE5v2pOVgo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307372; c=relaxed/simple; bh=FVndD1oHcIMjhy2ouwYkE607YpRHYdSxW4FCyGENAiw=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PAMUPR1MWgCnjr4DdjTsOBeNy4I1Ia7jE3L68spoFEXUXDqCMozcx6KfRw4RdtMBzzIXHopylOJe9kZ/0N9C2OpY31CvGH4QKQpmvPXcxNRQy7LPkFxWn4JoqGtCUmG0nQNXF9cz8CfvQCXCZ4f1Rk2oiZEZYFOUIGk5Pv1iOX0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=qbYRLeHp; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="qbYRLeHp" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=QhxWEZ3D4GGmGtUoAYImLv2QXaO4Fc0oYtFF+i9F/fc=; b=qbYRLeHp3CzOuhWLmUVjc/xI4t8fsvMlwzgt1dRaPPKlK0ILnR1NVoezIWLnyFHrMqcX9XWXR aJWfn6s6A2rP16ZYwfYMzQIICou/TDBgX545GfSH2FJqVO+duRvfcuAWg4mGi3DrFogTtSokT0a TQhPrfCFCeC3vzkMl0Jc+WM= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gTTVr2VM7z12LGX; Mon, 1 Jun 2026 17:41:24 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 2E70F201E9; Mon, 1 Jun 2026 17:49:21 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:17 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 12/23] arm64: kexec_file: Fix TOCTOU buffer overflow via memory region padding Date: Mon, 1 Jun 2026 17:47:54 +0800 Message-ID: <20260601094805.2928614-13-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out there is a TOCTOU (Time-of-Check to Time-of-Use) race condition in prepare_elf_headers() between the initial pass that counts System RAM ranges and the second pass that populates them. If a memory hotplug event occurs between these two steps, the number of memory regions may increase, causing an out-of-bounds write to the cmem->ranges[] array. Fix this fundamentally by using `CRASH_HOTPLUG_SAFETY_PADDING` (128 slots) to expand the flexible array allocation ceiling upfront. This safely absorbs any concurrent memory region expansion. Concurrently, add a defensive boundary check to return -EAGAIN on unexpected overrun, fully eradicating the overflow window and ensuring system stability. Cc: Catalin Marinas Cc: Will Deacon Cc: Andrew Morton Cc: Baoquan He Cc: Breno Leitao Cc: stable@vger.kernel.org Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support") Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/machine_kexec_file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index 4cbb71e1f8ed..8a96fb68b88d 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -48,7 +48,8 @@ int prepare_elf_headers(void **addr, unsigned long *sz) u64 i; phys_addr_t start, end; =20 - nr_ranges =3D 2; /* for exclusion of crashkernel region */ + /* for exclusion of crashkernel region */ + nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; for_each_mem_range(i, &start, &end) nr_ranges++; =20 @@ -59,6 +60,11 @@ int prepare_elf_headers(void **addr, unsigned long *sz) cmem->max_nr_ranges =3D nr_ranges; cmem->nr_ranges =3D 0; for_each_mem_range(i, &start, &end) { + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) { + ret =3D -EAGAIN; + goto out; + } + cmem->ranges[cmem->nr_ranges].start =3D start; cmem->ranges[cmem->nr_ranges].end =3D end - 1; cmem->nr_ranges++; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 512C939C649; Mon, 1 Jun 2026 09:49:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307379; cv=none; b=QdY6sEtJVuqz85tbI0ouggjxNbn9GeykJuYpN5aPUMNy+X8FvnPTnD4syLH5RjODJki0Zg1LLdbOjAuAmhLtxa3dmYKMYGj+sZCnwajPN5ZCqJFgLfoqth7f9DVBIa7Vr04XIe+qUwgNdQxd9Jp4ctF3F056tbpyas7H1yqTdc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307379; c=relaxed/simple; bh=u7ZzLF0Hb1ZVFevOmbl2C8PBqk0xuxiknP7FKKuanf4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aHy63WfRSWW1j6KRVCoO5MelAtGmc0uv+by7L3QDTnrKvdY9LJiOHT6NdIgsZ8lj+XMDoZyDZMZgCzQUQj+Y87sII0EQUJ5Fc4HRJqslmdNQdyatg/Cv+vKPOi4zAv1D2cdymCjKzVGc+DjqkQYvGid2MHlC2/UwfrBh/MKGAeg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=VhBDZrFR; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="VhBDZrFR" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=s72FvUjFSjSJ20RjP7SnGlVB1x5o5hIMnFQNqmBErV8=; b=VhBDZrFR76i+VElm85yQCdwAmgLAAAj/GvMjgfKMrBNw8K6sW8djbL99FteZAzdBUPwmwpKFk D4rYAMPPIAddb5+2EpnwbeiRUn1efqXA6Jhh4h/Ib5wbAcxehRl+0QOXweoQyRt6xn/C6WYYscJ hWU4wb+ZmFTyxSIQZRnfEyA= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWL17qkzpStn; Mon, 1 Jun 2026 17:41:50 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 1440340569; Mon, 1 Jun 2026 17:49:25 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:21 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 13/23] riscv: kexec_file: Fix TOCTOU buffer overflow via memory region padding Date: Mon, 1 Jun 2026 17:47:55 +0800 Message-ID: <20260601094805.2928614-14-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out there is a TOCTOU (Time-of-Check to Time-of-Use) race condition in prepare_elf_headers() between the initial pass that counts System RAM ranges and the second pass that populates them. If a memory hotplug event occurs between these two steps, the number of memory regions may increase, causing an out-of-bounds write to the cmem->ranges[] array. Fix this fundamentally by using `CRASH_HOTPLUG_SAFETY_PADDING` (128 slots) to expand the flexible array allocation ceiling upfront. This safely absorbs any concurrent memory region expansion. Concurrently, add a defensive boundary check inside the callback to return -EAGAIN on unexpected overrun, fully eradicating the overflow window and ensuring system stability. Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Cc: songshuaishuai@tinylab.org Cc: bjorn@rivosinc.com Cc: leitao@debian.org Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic") Reviewed-by: Guo Ren Signed-off-by: Jinjie Ruan --- arch/riscv/kernel/machine_kexec_file.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/mac= hine_kexec_file.c index 3f7766057cac..f3576dc0513f 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -48,6 +48,9 @@ static int prepare_elf64_ram_headers_callback(struct reso= urce *res, void *arg) { struct crash_mem *cmem =3D arg; =20 + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) + return -EAGAIN; + cmem->ranges[cmem->nr_ranges].start =3D res->start; cmem->ranges[cmem->nr_ranges].end =3D res->end; cmem->nr_ranges++; @@ -61,7 +64,8 @@ static int prepare_elf_headers(void **addr, unsigned long= *sz) unsigned int nr_ranges; int ret; =20 - nr_ranges =3D 2; /* For exclusion of crashkernel region */ + /* For exclusion of crashkernel region */ + nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); =20 cmem =3D kmalloc_flex(*cmem, ranges, nr_ranges); --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC8493A6B82; Mon, 1 Jun 2026 09:49:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307381; cv=none; b=aUG1GlWAfgd7AHTde5j31Rl6pfVvqFk16led8Q1dzCNmuW1Pp4wza/lN10z9Hfo5jf+Mjc2V3dgL4sJoVKvHtOoYFzeNyTMRZ/ac0WMtrKRUvRTMoPU5EXbTsbwE5BF/Ef27HtP4qzCmkYSzJmyAhIVOhzfcZpaxJnme6NaQFqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307381; c=relaxed/simple; bh=Mj3PReSCs06jFbirtSlzILbD40iBcltqW8B+HHT4RQQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MXkAbS2Ik/Hxip0v/1nHtwxE6xsHAH2VTIdM5ItnxD79Y9+XHdL1bT8b6UAP6QJpLujoqGFfI3cUGm6ejSBGseJi9LwXM/cv3Xbqvx5geT0sH15VPe7KPCUfvDc1eGNInpCanbmlQUvx8xCklR90lB1ZQXhiL+RXuvgEsNvSQvM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=6PEkMrvD; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="6PEkMrvD" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=K+OiX4qzF9ZF7Yx2d0GnuFscPpt9fElzoamptIjOMIU=; b=6PEkMrvD8QwvG/Qh8st7O555IPcpZY1yUBR9xKCs1T8D6EkfggsVhqLn2vRBf/VV54OMTqMFc 8JLeZNIiExCm/NunZ0NVTUCvGhqzT0UkLHmFRrbXfroj23ki6QFGBSAayUm9W96Cu1fsF699YIs 6BNwUZJfmCGZIL1ilqpJjoU= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4gTTW55FRTz1prL8; Mon, 1 Jun 2026 17:41:37 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id EF66D201E9; Mon, 1 Jun 2026 17:49:28 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:24 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 14/23] LoongArch: kexec_file: Fix TOCTOU buffer overflow via memory region padding Date: Mon, 1 Jun 2026 17:47:56 +0800 Message-ID: <20260601094805.2928614-15-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Sashiko AI code review pointed out there is a TOCTOU (Time-of-Check to Time-of-Use) race condition in prepare_elf_headers() between the initial pass that counts System RAM ranges and the second pass that populates them. If a memory hotplug event occurs between these two steps, the number of memory regions may increase, causing an out-of-bounds write to the cmem->ranges[] array. Fix this fundamentally by using `CRASH_HOTPLUG_SAFETY_PADDING` (128 slots) to expand the flexible array allocation ceiling upfront. This safely absorbs any concurrent memory region expansion. Concurrently, add a defensive boundary check to return -EAGAIN on unexpected overrun, fully eradicating the overflow window and ensuring system stability. Cc: Youling Tang Cc: Huacai Chen Cc: WANG Xuerui Cc: stable@vger.kernel.org Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file") Signed-off-by: Jinjie Ruan --- arch/loongarch/kernel/machine_kexec_file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/ke= rnel/machine_kexec_file.c index 5584b798ba46..3c369124586e 100644 --- a/arch/loongarch/kernel/machine_kexec_file.c +++ b/arch/loongarch/kernel/machine_kexec_file.c @@ -64,7 +64,8 @@ static int prepare_elf_headers(void **addr, unsigned long= *sz) phys_addr_t start, end; struct crash_mem *cmem; =20 - nr_ranges =3D 2; /* for exclusion of crashkernel region */ + /* for exclusion of crashkernel region */ + nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; for_each_mem_range(i, &start, &end) nr_ranges++; =20 @@ -75,6 +76,11 @@ static int prepare_elf_headers(void **addr, unsigned lon= g *sz) cmem->max_nr_ranges =3D nr_ranges; cmem->nr_ranges =3D 0; for_each_mem_range(i, &start, &end) { + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) { + ret =3D -EAGAIN; + goto out; + } + cmem->ranges[cmem->nr_ranges].start =3D start; cmem->ranges[cmem->nr_ranges].end =3D end - 1; cmem->nr_ranges++; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7B093A759D; Mon, 1 Jun 2026 09:49:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307387; cv=none; b=iuvEKv0PbBKDA8fPrqOpL/0xHh92YBaEip1GLmoKrlXuJhOtIAm+03LkNrR0VZsMj8ylfdtyWWhLPUfVSyZ8IN6lqBVB0nulMKEKXAcHwSHCtbJ2mBkyHtYgDgGZcC/dySsQlPe4I1We9kuLo8kYr9Xp+8vqRu9me0DDPbhjlr4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307387; c=relaxed/simple; bh=/opy0FzphCo07Eb8nprEeZp5+BecXG7+97Xwa6zitTE=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NY2TS8PmVBWmHEDzUMfxYs6B6W3KDDe1XW55j+kmrRDfFbfxO7h0sVdylLfOnN3plLvut3THjL3xM9ZfYbkulp51yueKr+fNBqCCgWQnTyemELu0Atwe64XFxyHsl0K0+RNrG8bxChoUMRUdoJ3rOKd/zfoqG90teQW3VZwMzlM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=IS8WuSNs; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="IS8WuSNs" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=SrEXz0arLSVrbm1mpuiSPB9eZ8Fyzn3PPfNKkeXX+zc=; b=IS8WuSNs2LAjRMLP4plK+AZtp42WrAR7O261xjjQR/hnnIifhjOtP72l32ZEXmJDgCnqJf+ca RM5szP5tdfnAWRK3WxfUTRSrC3pFMYaM1RmbOttpDq6mnmmpvG5fFDTwmbwVkqz9a2/pYu4GRRW BnPWtecQ4t80MDGPhMpHSNI= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWB6zC5zmV7H; Mon, 1 Jun 2026 17:41:42 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id E11DF4056C; Mon, 1 Jun 2026 17:49:32 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:28 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 15/23] crash: Add crash_prepare_headers() to exclude crash kernel memory Date: Mon, 1 Jun 2026 17:47:57 +0800 Message-ID: <20260601094805.2928614-16-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" The crash memory alloc, and the exclude of crashk_res, crashk_low_res and crashk_cma memory are almost identical across different architectures, handling them in the crash core would eliminate a lot of duplication, so add crash_prepare_headers() helper to handle them in the common code. To achieve the above goal, three architecture-specific functions are introduced: - arch_get_system_nr_ranges(). Pre-counts the max number of memory ranges. - arch_crash_populate_cmem(). Collects the memory ranges and fills them into cmem. - arch_crash_exclude_ranges(). Architecture's additional crash memory ranges exclusion, defaulting to empty. Reviewed-by: Sourabh Jain Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- include/linux/crash_core.h | 5 +++ kernel/crash_core.c | 82 ++++++++++++++++++++++++++++++++++++-- 2 files changed, 84 insertions(+), 3 deletions(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index d4762e000098..43baf9c87355 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -65,6 +65,8 @@ extern int crash_exclude_mem_range(struct crash_mem *mem, unsigned long long mend); extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_ker= nel_map, void **addr, unsigned long *sz); +extern int crash_prepare_headers(int need_kernel_map, void **addr, + unsigned long *sz, unsigned long *nr_mem_ranges); =20 struct kimage; struct kexec_segment; @@ -82,6 +84,9 @@ int kexec_should_crash(struct task_struct *p); int kexec_crash_loaded(void); void crash_save_cpu(struct pt_regs *regs, int cpu); extern int kimage_crash_copy_vmcoreinfo(struct kimage *image); +extern unsigned int arch_get_system_nr_ranges(void); +extern int arch_crash_populate_cmem(struct crash_mem *cmem); +extern int arch_crash_exclude_ranges(struct crash_mem *cmem); =20 #else /* !CONFIG_CRASH_DUMP*/ struct pt_regs; diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 4f21fc3b108b..481babc29131 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -168,9 +168,6 @@ static inline resource_size_t crash_resource_size(const= struct resource *res) return !res->end ? 0 : resource_size(res); } =20 - - - int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map, void **addr, unsigned long *sz) { @@ -272,6 +269,85 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,= int need_kernel_map, return 0; } =20 +static struct crash_mem *alloc_cmem(unsigned int nr_ranges) +{ + struct crash_mem *cmem; + + cmem =3D kvzalloc_flex(*cmem, ranges, nr_ranges); + if (!cmem) + return NULL; + + cmem->max_nr_ranges =3D nr_ranges; + return cmem; +} + +unsigned int __weak arch_get_system_nr_ranges(void) { return 0; } +int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; } +int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; } + +static int crash_exclude_core_ranges(struct crash_mem *cmem) +{ + int ret, i; + + /* Exclude crashkernel region */ + ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); + if (ret) + return ret; + + if (crashk_low_res.end) { + ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); + if (ret) + return ret; + } + + for (i =3D 0; i < crashk_cma_cnt; ++i) { + ret =3D crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, + crashk_cma_ranges[i].end); + if (ret) + return ret; + } + + return 0; +} + +int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long = *sz, + unsigned long *nr_mem_ranges) +{ + unsigned int max_nr_ranges; + struct crash_mem *cmem; + int ret; + + max_nr_ranges =3D arch_get_system_nr_ranges(); + if (!max_nr_ranges) + return -ENOMEM; + + cmem =3D alloc_cmem(max_nr_ranges); + if (!cmem) + return -ENOMEM; + + ret =3D arch_crash_populate_cmem(cmem); + if (ret) + goto out; + + ret =3D crash_exclude_core_ranges(cmem); + if (ret) + goto out; + + ret =3D arch_crash_exclude_ranges(cmem); + if (ret) + goto out; + + /* Return the computed number of memory ranges, for hotplug usage */ + if (nr_mem_ranges) + *nr_mem_ranges =3D cmem->nr_ranges; + + ret =3D crash_prepare_elf64_headers(cmem, need_kernel_map, addr, sz); + +out: + kvfree(cmem); + return ret; +} + /** * crash_exclude_mem_range - exclude a mem range for existing ranges * @mem: mem->range contains an array of ranges sorted in ascending order --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 953D23A7F6B; Mon, 1 Jun 2026 09:49:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307391; cv=none; b=s3ezMXwECd5VIWKlT7IX76kyfTvs8Iwgwpy8VwI6yAxYasJiM3XzTVdkQo/i3Tj+NgkmoSOyJQLw8mGfpoU4YCr5FJMFAtHwrVC5kLbybHwiMvwr8RWvCSvxIfCG4mYPsi7JpyD6QEZ+2l5cZoridVK/Y10aZeK1uhZFobLsRjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307391; c=relaxed/simple; bh=CIUH516Z9a68NrK+XUkWd+q/jzkFO42pX0nvYcqpjSU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Qpm2ReasdJsAN0QMJ71X90RzCWtCEmxw27YTFZTssVgGyYLe3YcZY9JI6JmD8/v23ju74VLccWMswiH0B5o8YM+tuIqJY3/uBgp0Y6ESIEGdTQZzdBH1rFSPGyJmeUcH8a4QeQBGzEsAZkR9trGxBUKYby1FeFN4A+cFuPBO6DM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Pxk/qx0q; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Pxk/qx0q" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Di6OVIZCi2oSHSZQ2khRgdHDqfvYWAdAD/zWW8h2auU=; b=Pxk/qx0q1w/lxVslB1W6s5P8m+jT5DYow42lGfztBtmZ3PBCmrWGxGLbDWOQL+lsetoIIQfuD 499XW+ULQvl2w9uSD/NeKqR+tuRUApn17cIOgVVBVEWnmCeklHeiuVVJhcV4SeWysL2p3M0VB2Y 959UnPosDn/WjQmoLXHUTuI= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWF460nz1prLf; Mon, 1 Jun 2026 17:41:45 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id C73D940538; Mon, 1 Jun 2026 17:49:36 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:32 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 16/23] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code Date: Mon, 1 Jun 2026 17:47:58 +0800 Message-ID: <20260601094805.2928614-17-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following two architecture functions need to be implemented: - arch_get_system_nr_ranges(). Use for_each_mem_range() to traverse and pre-count the max number of memory ranges. - arch_crash_populate_cmem(). Use for_each_mem_range to traverse and collect the memory ranges and fills them into cmem. Acked-by: Catalin Marinas Reviewed-by: Sourabh Jain Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/kexec.h | 1 - arch/arm64/kernel/kexec_image.c | 2 +- arch/arm64/kernel/machine_kexec_file.c | 46 ++++++++------------------ 3 files changed, 15 insertions(+), 34 deletions(-) diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h index 7ffa2ff5fcfd..892e5bebda95 100644 --- a/arch/arm64/include/asm/kexec.h +++ b/arch/arm64/include/asm/kexec.h @@ -128,7 +128,6 @@ extern int load_other_segments(struct kimage *image, unsigned long kernel_load_addr, unsigned long kernel_size, char *initrd, unsigned long initrd_len, char *cmdline); -extern int prepare_elf_headers(void **addr, unsigned long *sz); #endif =20 #endif /* __ASSEMBLER__ */ diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_imag= e.c index 424b9527db09..93c36a3aa618 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -95,7 +95,7 @@ static void *image_load(struct kimage *image, unsigned long headers_sz; void *headers; =20 - ret =3D prepare_elf_headers(&headers, &headers_sz); + ret =3D crash_prepare_headers(true, &headers, &headers_sz, NULL); if (ret) { pr_err("Preparing elf core header failed\n"); return ERR_PTR(ret); diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index 8a96fb68b88d..14e65351133e 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -40,52 +40,34 @@ int arch_kimage_file_post_load_cleanup(struct kimage *i= mage) } =20 #ifdef CONFIG_CRASH_DUMP -int prepare_elf_headers(void **addr, unsigned long *sz) +unsigned int arch_get_system_nr_ranges(void) { - struct crash_mem *cmem; - unsigned int nr_ranges; - int ret; - u64 i; + /* for exclusion of crashkernel region */ + unsigned int nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; phys_addr_t start, end; + u64 i; =20 - /* for exclusion of crashkernel region */ - nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; for_each_mem_range(i, &start, &end) nr_ranges++; =20 - cmem =3D kmalloc_flex(*cmem, ranges, nr_ranges); - if (!cmem) - return -ENOMEM; + return nr_ranges; +} + +int arch_crash_populate_cmem(struct crash_mem *cmem) +{ + phys_addr_t start, end; + u64 i; =20 - cmem->max_nr_ranges =3D nr_ranges; - cmem->nr_ranges =3D 0; for_each_mem_range(i, &start, &end) { - if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) { - ret =3D -EAGAIN; - goto out; - } + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) + return -EAGAIN; =20 cmem->ranges[cmem->nr_ranges].start =3D start; cmem->ranges[cmem->nr_ranges].end =3D end - 1; cmem->nr_ranges++; } =20 - /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); - if (ret) - goto out; - - if (crashk_low_res.end) { - ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); - if (ret) - goto out; - } - - ret =3D crash_prepare_elf64_headers(cmem, true, addr, sz); - -out: - kfree(cmem); - return ret; + return 0; } #endif =20 --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B57E03A962E; Mon, 1 Jun 2026 09:49:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307395; cv=none; b=U1n0DJE7sMvlP71vsT1YHE3+xxoV85YUKx6mKBfIK2sciPCVX5HMzU7XsVh9wtFSuc0gJATq7rSWpcwklTrZCZXP7jRjWPmjyxcTc8x9FEvWZmTlHk5YPGqXTHG6PEA1K8jUpGw2Q8WavSUrP95JOJkP+i0zIwVQu1j+iqDBzu8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307395; c=relaxed/simple; bh=CRwJb1FoyHetgnUvMRfYur62CSNZqeutfZU94nJ1RpE=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Vfl8kRj7NVBciM2h68/Yl1eOiFQ6egncqG6Y5sjE8bWBATfP+oCfGcIVNsC3CROSdSuzTJ+olOVsQ1CfLuVCCF3r3q/ZulH2pMpdOG76BZf+D0xU6Z26/xidjhdgcFsh/L0cGuAoCvXuZKFPhwHv2+3mN619x2Nyr4ANtmSUoTw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=bf/+zrAO; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="bf/+zrAO" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=PQjCOuksxFLNJ/PXARosmcN2Kk75oOKMkd0S/i+oF2A=; b=bf/+zrAOi95jCOnI9Di7s9i4dzpBBQ8i33XohqYB1B/FHXZD/Ezyhezu5+2D5WL1vsfY0bJWi 6XFOogRXZ1G7dPJd0fb3ausJe8j9KI60XL84OCfh2jmDzhHV50LUYB63VV4ZptTO54vmbvJFqTn vl6aq2y1cxIkUzCbF58MCo0= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWd5fZbzpStn; Mon, 1 Jun 2026 17:42:05 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id B32FF201E9; Mon, 1 Jun 2026 17:49:40 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:36 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 17/23] x86: kexec_file: Use crash_prepare_headers() helper to simplify code Date: Mon, 1 Jun 2026 17:47:59 +0800 Message-ID: <20260601094805.2928614-18-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following three architecture functions need to be implemented: - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback() to pre-count the max number of memory ranges. - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback() to collect the memory ranges and fills them into cmem. - arch_crash_exclude_ranges(). Exclude the low 1M for x86. By the way, remove the unused "nr_mem_ranges" in arch_crash_handle_hotplug_event(). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Andrew Morton Cc: Vivek Goyal Reviewed-by: Sourabh Jain Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- arch/x86/kernel/crash.c | 89 +++++------------------------------------ 1 file changed, 11 insertions(+), 78 deletions(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index a1089907728d..7145b00da4ee 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -153,16 +153,8 @@ static int get_nr_ram_ranges_callback(struct resource = *res, void *arg) return 0; } =20 -/* Gather all the required information to prepare elf headers for ram regi= ons */ -static struct crash_mem *fill_up_crash_elf_data(void) +unsigned int arch_get_system_nr_ranges(void) { - unsigned int nr_ranges =3D 0; - struct crash_mem *cmem; - - walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); - if (!nr_ranges) - return NULL; - /* * Exclusion of crash region, crashk_low_res and/or crashk_cma_ranges * may cause range splits. So add extra slots here. @@ -177,49 +169,16 @@ static struct crash_mem *fill_up_crash_elf_data(void) * But in order to lest the low 1M could be changed in the future, * (e.g. [start, 1M]), add a extra slot. */ - nr_ranges +=3D 3 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADDING; - cmem =3D vzalloc(struct_size(cmem, ranges, nr_ranges)); - if (!cmem) - return NULL; - - cmem->max_nr_ranges =3D nr_ranges; + unsigned int nr_ranges =3D 3 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADD= ING; =20 - return cmem; + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); + return nr_ranges; } =20 -/* - * Look for any unwanted ranges between mstart, mend and remove them. This - * might lead to split and split ranges are put in cmem->ranges[] array - */ -static int elf_header_exclude_ranges(struct crash_mem *cmem) +int arch_crash_exclude_ranges(struct crash_mem *cmem) { - int ret =3D 0; - int i; - /* Exclude the low 1M because it is always reserved */ - ret =3D crash_exclude_mem_range(cmem, 0, SZ_1M - 1); - if (ret) - return ret; - - /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); - if (ret) - return ret; - - if (crashk_low_res.end) - ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, - crashk_low_res.end); - if (ret) - return ret; - - for (i =3D 0; i < crashk_cma_cnt; ++i) { - ret =3D crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, - crashk_cma_ranges[i].end); - if (ret) - return ret; - } - - return 0; + return crash_exclude_mem_range(cmem, 0, SZ_1M - 1); } =20 static int prepare_elf64_ram_headers_callback(struct resource *res, void *= arg) @@ -236,35 +195,9 @@ static int prepare_elf64_ram_headers_callback(struct r= esource *res, void *arg) return 0; } =20 -/* Prepare elf headers. Return addr and size */ -static int prepare_elf_headers(void **addr, unsigned long *sz, - unsigned long *nr_mem_ranges) +int arch_crash_populate_cmem(struct crash_mem *cmem) { - struct crash_mem *cmem; - int ret; - - cmem =3D fill_up_crash_elf_data(); - if (!cmem) - return -ENOMEM; - - ret =3D walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callba= ck); - if (ret) - goto out; - - /* Exclude unwanted mem ranges */ - ret =3D elf_header_exclude_ranges(cmem); - if (ret) - goto out; - - /* Return the computed number of memory ranges, for hotplug usage */ - *nr_mem_ranges =3D cmem->nr_ranges; - - /* By default prepare 64bit headers */ - ret =3D crash_prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), addr= , sz); - -out: - vfree(cmem); - return ret; + return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callbac= k); } #endif =20 @@ -422,7 +355,8 @@ int crash_load_segments(struct kimage *image) .buf_max =3D ULONG_MAX, .top_down =3D false }; =20 /* Prepare elf headers and add a segment */ - ret =3D prepare_elf_headers(&kbuf.buffer, &kbuf.bufsz, &pnum); + ret =3D crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &kbuf.buffer, + &kbuf.bufsz, &pnum); if (ret) return ret; =20 @@ -515,7 +449,6 @@ unsigned int arch_crash_get_elfcorehdr_size(void) void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { void *elfbuf =3D NULL, *old_elfcorehdr; - unsigned long nr_mem_ranges; unsigned long mem, memsz; unsigned long elfsz =3D 0; =20 @@ -533,7 +466,7 @@ void arch_crash_handle_hotplug_event(struct kimage *ima= ge, void *arg) * Create the new elfcorehdr reflecting the changes to CPU and/or * memory resources. */ - if (prepare_elf_headers(&elfbuf, &elfsz, &nr_mem_ranges)) { + if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NUL= L)) { pr_err("unable to create new elfcorehdr"); goto out; } --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout12.his.huawei.com (canpmsgout12.his.huawei.com [113.46.200.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E9DD3ACA51; Mon, 1 Jun 2026 09:49:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.227 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307408; cv=none; b=OKxFbZ0xwXfo8z9SmNZMAHnhz53iFELsqvhe2IcEHRAPtR1nGFD7BqMj73/hHsEeNxQpZarPjZAOXSM5zN/uVGelhjfsen724joR9UcdieieTxmEy6LHlS+7gS3HWC7qCVESEHzlOJU/DLx6XCDnxyceSLZMgl7jHJIKgLEA0ms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307408; c=relaxed/simple; bh=DnuJ8MTNoX8VL3UjkEOfZOvIsgp0cqve8WR78wh8HH8=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=r0BrnZzhrekPu1Yiigsq1sPJualO9yLQ3UgbXBlgkYEnaO7HM07+xnhOoKosBcJsB6vYHCu6S8EDK/KE8tkU/P+Vv/le+qvY/mZDjGGNvx860CmQwLkz2kI10ojeBAiec9zhFzn5LafLLwTZEETiQTQGqbdHthf/RaKCMf8XEbA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=mS7gkiH2; arc=none smtp.client-ip=113.46.200.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="mS7gkiH2" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=frzGmIOj99V2r64L7a8e+rlKnHjd0zMn3ig4b5s7qY0=; b=mS7gkiH2dGhIoSKGtoTWyAewmvp6gOB6dLP5+6oxlYySTBRhXNvWi45ZkKaY2BkLksFCgXbwU RHNUZoF4VpvM19xa8VK6ZFbEK1wDxmJ/Vxzi0JZMp9AArq6KP5/a89+GIa756akZX/VCqYQZ6Ar fHDJ1eV9LU+DG2w64UAIZzU= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWL31dVznTXy; Mon, 1 Jun 2026 17:41:50 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 9F86540563; Mon, 1 Jun 2026 17:49:44 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:40 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 18/23] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code Date: Mon, 1 Jun 2026 17:48:00 +0800 Message-ID: <20260601094805.2928614-19-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following two architecture functions need to be implemented: - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback() to pre-counts the max number of memory ranges. - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback() to collects the memory ranges and fills them into cmem. Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Cc: Guo Ren Reviewed-by: Sourabh Jain Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- arch/riscv/kernel/machine_kexec_file.c | 49 +++++++------------------- 1 file changed, 13 insertions(+), 36 deletions(-) diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/mac= hine_kexec_file.c index f3576dc0513f..6e2a6747d187 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -44,6 +44,16 @@ static int get_nr_ram_ranges_callback(struct resource *r= es, void *arg) return 0; } =20 +unsigned int arch_get_system_nr_ranges(void) +{ + /* For exclusion of crashkernel region */ + unsigned int nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; + + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); + + return nr_ranges; +} + static int prepare_elf64_ram_headers_callback(struct resource *res, void *= arg) { struct crash_mem *cmem =3D arg; @@ -58,42 +68,9 @@ static int prepare_elf64_ram_headers_callback(struct res= ource *res, void *arg) return 0; } =20 -static int prepare_elf_headers(void **addr, unsigned long *sz) +int arch_crash_populate_cmem(struct crash_mem *cmem) { - struct crash_mem *cmem; - unsigned int nr_ranges; - int ret; - - /* For exclusion of crashkernel region */ - nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; - walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); - - cmem =3D kmalloc_flex(*cmem, ranges, nr_ranges); - if (!cmem) - return -ENOMEM; - - cmem->max_nr_ranges =3D nr_ranges; - cmem->nr_ranges =3D 0; - ret =3D walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callba= ck); - if (ret) - goto out; - - /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); - if (ret) - goto out; - - if (crashk_low_res.end) { - ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); - if (ret) - goto out; - } - - ret =3D crash_prepare_elf64_headers(cmem, true, addr, sz); - -out: - kfree(cmem); - return ret; + return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callbac= k); } =20 static char *setup_kdump_cmdline(struct kimage *image, char *cmdline, @@ -285,7 +262,7 @@ int load_extra_segments(struct kimage *image, unsigned = long kernel_start, if (image->type =3D=3D KEXEC_TYPE_CRASH) { void *headers; unsigned long headers_sz; - ret =3D prepare_elf_headers(&headers, &headers_sz); + ret =3D crash_prepare_headers(true, &headers, &headers_sz, NULL); if (ret) { pr_err("Preparing elf core header failed\n"); goto out; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 435B839DBF9; Mon, 1 Jun 2026 09:49:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307401; cv=none; b=Xv4bW07ay0TqputbYJp0zQw7ukiTvOqbpDIeXd5Yok+ZpjIPK2paY/lBOQT8dYIka+wVa4l2DmA51jaE57fLPORTz4f1sITCM5voCdffT6TvpprsyrnGNhRTMMA1ZNuDmSdVYJY/sZoNWAwTSSRq1E7OI2sL8PRt8B2trBxWb9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307401; c=relaxed/simple; bh=1RE0ggCL1H2sdgdLvrLrLZEad9yWGiCCsWwC54raKX0=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dXGlSJkAw2+1Xe5LUScdRU715hKmmhzmedA9ZB11ijBXgmXUwVmw+dsje2jP6w1BWlM3MA6/IN9kMQvqeASuQMtMtqCMb+H0MpnBgqKV5dx6R3FyL68EHxTGGbqMZlk+PUwTpsaltEElSm+EGt5mKZSkdqAiEwygLisIUQP4k4I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=r9ZH1ej6; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="r9ZH1ej6" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=VWBV2U5yMqcbh55EfObhiotNmBAp32Br2+ez2EoTpng=; b=r9ZH1ej6irADfT920XCGsNsznQD6yaMW19Luu1KKuC4Ox05HYGKMHMLbII4nYiAtxt+71DWk0 1DM+CHqbX5q/kzgSTvf7G65UhYBCRcchDTXMVus5Ri3KMrBxZEbUz1D6gP0zk1Fpt0/im4+E3Ey ER+lFBDEgbNoYLR/APqpYQE= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWX1QtdzLlwm; Mon, 1 Jun 2026 17:42:00 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 8591A40563; Mon, 1 Jun 2026 17:49:48 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:44 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 19/23] LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify code Date: Mon, 1 Jun 2026 17:48:01 +0800 Message-ID: <20260601094805.2928614-20-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following two architecture functions need to be implemented: - arch_get_system_nr_ranges(). Use for_each_mem_range to traverse and pre-count the max number of memory ranges. - arch_crash_populate_cmem(). Use for_each_mem_range to traverse and collect the memory ranges and fills them into cmem. Cc: Huacai Chen Cc: WANG Xuerui Cc: Youling Tang Cc: Baoquan He Reviewed-by: Sourabh Jain Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- arch/loongarch/kernel/machine_kexec_file.c | 48 +++++++--------------- 1 file changed, 15 insertions(+), 33 deletions(-) diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/ke= rnel/machine_kexec_file.c index 3c369124586e..f3101bea9e45 100644 --- a/arch/loongarch/kernel/machine_kexec_file.c +++ b/arch/loongarch/kernel/machine_kexec_file.c @@ -56,52 +56,34 @@ static void cmdline_add_initrd(struct kimage *image, un= signed long *cmdline_tmpl } =20 #ifdef CONFIG_CRASH_DUMP - -static int prepare_elf_headers(void **addr, unsigned long *sz) +unsigned int arch_get_system_nr_ranges(void) { - int ret, nr_ranges; - uint64_t i; + /* for exclusion of crashkernel region */ + int nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; phys_addr_t start, end; - struct crash_mem *cmem; + uint64_t i; =20 - /* for exclusion of crashkernel region */ - nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; for_each_mem_range(i, &start, &end) nr_ranges++; =20 - cmem =3D kmalloc_flex(*cmem, ranges, nr_ranges); - if (!cmem) - return -ENOMEM; + return nr_ranges; +} + +int arch_crash_populate_cmem(struct crash_mem *cmem) +{ + phys_addr_t start, end; + uint64_t i; =20 - cmem->max_nr_ranges =3D nr_ranges; - cmem->nr_ranges =3D 0; for_each_mem_range(i, &start, &end) { - if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) { - ret =3D -EAGAIN; - goto out; - } + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) + return -EAGAIN; =20 cmem->ranges[cmem->nr_ranges].start =3D start; cmem->ranges[cmem->nr_ranges].end =3D end - 1; cmem->nr_ranges++; } =20 - /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); - if (ret < 0) - goto out; - - if (crashk_low_res.end) { - ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); - if (ret < 0) - goto out; - } - - ret =3D crash_prepare_elf64_headers(cmem, true, addr, sz); - -out: - kfree(cmem); - return ret; + return 0; } =20 /* @@ -169,7 +151,7 @@ int load_other_segments(struct kimage *image, void *headers; unsigned long headers_sz; =20 - ret =3D prepare_elf_headers(&headers, &headers_sz); + ret =3D crash_prepare_headers(true, &headers, &headers_sz, NULL); if (ret < 0) { pr_err("Preparing elf core header failed\n"); goto out_err; --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5291F3ACA65; Mon, 1 Jun 2026 09:49:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307408; cv=none; b=oswUcHQAUKgQswvtm+l2ll2fz34e+ORYlClhv5i9meUz2xny/p2LNYmLj2h2ww016N8ffgJz2yJb+rEkWFR5tx7h5+sxzLKb/UrAmwg6p+bqKTkr5zjISPpgxhuadUGE52KrA2xcn/hw3yzWBjpRPmFPl79wvev+qKrDugj5/FQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307408; c=relaxed/simple; bh=+Y4gC7IdqdV5HqVIMcjf6aqtzVSUXTPjkgvxD1C8MQ4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WTdXbUOHCj/pxIUIKUdVG5+oqMf4mPua9gN7C0pAnKKUUr5aaqpSWn8WKpnwum202gPPZY1G55yWxLHoTYkev2YCgncA/0FeYMFhEqe2f+A77PoIKQYjMx63wm95yVEiCAjnR25KV942Mcux9x2x4r69z8C3lkmZVDbZLNAnfz4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Z9/j+bvJ; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Z9/j+bvJ" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=oARwP823mK2svk8EHr8oSkwE0woOoobvi75Jpwji2lk=; b=Z9/j+bvJ1QagwfLQ90H92i9ZbEtUnC8y/PaMvTnHcNbZycj4IoqqkPoI16NF4TDoPzXVtU4xB GKnbAXGH3mebCz5ExVBk8+Tetn/jfQe/Q3vNEMijJeD+d4bBG+ORjAublvi/LhHL4O7w9Vw+nFM rpqZTUoayxLQhW1WrZFZiUk= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWR4Kbbz12Lcs; Mon, 1 Jun 2026 17:41:55 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 7050D201E9; Mon, 1 Jun 2026 17:49:52 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:48 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 20/23] powerpc/kexec_file: Use crash_exclude_core_ranges() helper Date: Mon, 1 Jun 2026 17:48:02 +0800 Message-ID: <20260601094805.2928614-21-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" The crash memory exclude of crashk_res and crashk_cma memory on powerpc are almost identical to the generic crash_exclude_core_ranges(). By introducing the architecture-specific arch_crash_exclude_mem_range() function with a default implementation of crash_exclude_mem_range(), and using crash_exclude_mem_range_guarded as powerpc's separate implementation, the generic crash_exclude_core_ranges() helper function can be reused. Cc: Andrew Morton Cc: Hari Bathini Cc: Madhavan Srinivasan Cc: Mahesh Salgaonkar Cc: Michael Ellerman Cc: Ritesh Harjani (IBM) Cc: Shivang Upadhyay Acked-by: Baoquan He Reviewed-by: Sourabh Jain Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jinjie Ruan --- arch/powerpc/include/asm/kexec_ranges.h | 3 --- arch/powerpc/kexec/crash.c | 2 +- arch/powerpc/kexec/ranges.c | 16 ++++------------ include/linux/crash_core.h | 4 ++++ kernel/crash_core.c | 19 +++++++++++++------ 5 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include= /asm/kexec_ranges.h index ad95e3792d10..8489e844b447 100644 --- a/arch/powerpc/include/asm/kexec_ranges.h +++ b/arch/powerpc/include/asm/kexec_ranges.h @@ -7,9 +7,6 @@ void sort_memory_ranges(struct crash_mem *mrngs, bool merge); struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges); int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size); -int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges, - unsigned long long mstart, - unsigned long long mend); int get_exclude_memory_ranges(struct crash_mem **mem_ranges); int get_reserved_memory_ranges(struct crash_mem **mem_ranges); int get_crash_memory_ranges(struct crash_mem **mem_ranges); diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c index d634db67becc..775895f31037 100644 --- a/arch/powerpc/kexec/crash.c +++ b/arch/powerpc/kexec/crash.c @@ -513,7 +513,7 @@ static void update_crash_elfcorehdr(struct kimage *imag= e, struct memory_notify * base_addr =3D PFN_PHYS(mn->start_pfn); size =3D mn->nr_pages * PAGE_SIZE; end =3D base_addr + size - 1; - ret =3D crash_exclude_mem_range_guarded(&cmem, base_addr, end); + ret =3D arch_crash_exclude_mem_range(&cmem, base_addr, end); if (ret) { pr_err("Failed to remove hot-unplugged memory from crash memory ranges\= n"); goto out; diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c index b2fb78562cdc..539061d14a77 100644 --- a/arch/powerpc/kexec/ranges.c +++ b/arch/powerpc/kexec/ranges.c @@ -551,9 +551,9 @@ int get_usable_memory_ranges(struct crash_mem **mem_ran= ges) #endif /* CONFIG_KEXEC_FILE */ =20 #ifdef CONFIG_CRASH_DUMP -int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges, - unsigned long long mstart, - unsigned long long mend) +int arch_crash_exclude_mem_range(struct crash_mem **mem_ranges, + unsigned long long mstart, + unsigned long long mend) { struct crash_mem *tmem =3D *mem_ranges; =20 @@ -602,18 +602,10 @@ int get_crash_memory_ranges(struct crash_mem **mem_ra= nges) sort_memory_ranges(*mem_ranges, true); } =20 - /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range_guarded(mem_ranges, crashk_res.start, cra= shk_res.end); + ret =3D crash_exclude_core_ranges(mem_ranges); if (ret) goto out; =20 - for (i =3D 0; i < crashk_cma_cnt; ++i) { - ret =3D 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 diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 43baf9c87355..1ae2c0eb2eb3 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -67,6 +67,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *= mem, int need_kernel_ma void **addr, unsigned long *sz); extern int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz, unsigned long *nr_mem_ranges); +extern int crash_exclude_core_ranges(struct crash_mem **cmem); =20 struct kimage; struct kexec_segment; @@ -87,6 +88,9 @@ extern int kimage_crash_copy_vmcoreinfo(struct kimage *im= age); extern unsigned int arch_get_system_nr_ranges(void); extern int arch_crash_populate_cmem(struct crash_mem *cmem); extern int arch_crash_exclude_ranges(struct crash_mem *cmem); +extern int arch_crash_exclude_mem_range(struct crash_mem **mem, + unsigned long long mstart, + unsigned long long mend); =20 #else /* !CONFIG_CRASH_DUMP*/ struct pt_regs; diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 481babc29131..2b36aa9fade0 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -285,24 +285,31 @@ unsigned int __weak arch_get_system_nr_ranges(void) {= return 0; } int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; } int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; } =20 -static int crash_exclude_core_ranges(struct crash_mem *cmem) +int __weak arch_crash_exclude_mem_range(struct crash_mem **mem, + unsigned long long mstart, + unsigned long long mend) +{ + return crash_exclude_mem_range(*mem, mstart, mend); +} + +int crash_exclude_core_ranges(struct crash_mem **cmem) { int ret, i; =20 /* Exclude crashkernel region */ - ret =3D crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); + ret =3D arch_crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.e= nd); if (ret) return ret; =20 if (crashk_low_res.end) { - ret =3D crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_r= es.end); + ret =3D arch_crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_= low_res.end); if (ret) return ret; } =20 for (i =3D 0; i < crashk_cma_cnt; ++i) { - ret =3D crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, - crashk_cma_ranges[i].end); + ret =3D arch_crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, + crashk_cma_ranges[i].end); if (ret) return ret; } @@ -329,7 +336,7 @@ int crash_prepare_headers(int need_kernel_map, void **a= ddr, unsigned long *sz, if (ret) goto out; =20 - ret =3D crash_exclude_core_ranges(cmem); + ret =3D crash_exclude_core_ranges(&cmem); if (ret) goto out; =20 --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03A1C3A75A8; Mon, 1 Jun 2026 09:49:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307411; cv=none; b=hhdTycA+10ut/6+sAYy2ncWwcC1e6B94eFFFcyiltbbdfdrFhmfj+ZlFkUwe4fQHXuqAgUuLSW/MVSQ/fVig7Dn/9aA5ERfE7alpGl5daFZpuI4Y5/8epACHXawfOnWaYml782CoGT4QEQY40bMG0YTiaoQns9h73AyDU31SrAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307411; c=relaxed/simple; bh=GsBrIallTBQDwpyqk+h3OO+mog8FflyqdozfGyIltC4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NsticWKaxtTqlkDHWc8tL7ptYcg3vusuF8wsDOIuulS04pRG44wRfrwDlAyEbdlr04zwL8cZBVS/v7PwV5VZwRDqzwprch9YTOzd1POcdU4253MTBSWL7EqhodXLOIC1fARwvUHMkJnnBRXHAp2u2ESz2Xtzc6DyiYFSRAc0d74= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=PAcKayAm; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="PAcKayAm" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=JhYJvE/GhQydUAJcrbUk3aDyXMPQ/ckx7nLUeIZgB5Y=; b=PAcKayAmwzYGQXXcnlJ9zJ3jrC4/A2b51RtkifSRjjCtuTa0lUInTSzMedb1BuM8a6T+ONzv3 VTtsJd+pt3CAYeT3RW1i4ZitvR4Xa88yWPTSQXh+tdtKZOLfeYv4TeLAgizh0WO0YRvSqupgjr9 6/rYQ9+TTmf2yEQZNce1Jjw= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWx34pYzpSvD; Mon, 1 Jun 2026 17:42:21 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 5CFA04048F; Mon, 1 Jun 2026 17:49:56 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:52 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 21/23] arm64: kexec_file: Add support for crashkernel CMA reservation Date: Mon, 1 Jun 2026 17:48:03 +0800 Message-ID: <20260601094805.2928614-22-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel=3D command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. Crash kernel memory reservation wastes production resources if too large, risks kdump failure if too small, and faces allocation difficulties on fragmented systems due to contiguous block constraints. The new CMA-based crashkernel reservation scheme splits the "large fixed reservation" into a "small fixed region + large CMA dynamic region": the CMA memory is available to userspace during normal operation to avoid waste, and is reclaimed for kdump upon crash=E2=80=94saving memory while improving reliability. So extend crashkernel CMA reservation support to arm64. The following changes are made to enable CMA reservation: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use. - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, which is already done in the crash core. Update kernel-parameters.txt to document CMA support for crashkernel on arm64 architecture. Tested-by: Breno Leitao Acked-by: Catalin Marinas Acked-by: Rob Herring (Arm) Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Acked-by: Ard Biesheuvel Signed-off-by: Jinjie Ruan --- v7: - Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec. v3: - Add Acked-by. v2: - Free cmem in prepare_elf_headers() - Add the mtivation. --- Documentation/admin-guide/kernel-parameters.txt | 2 +- arch/arm64/kernel/machine_kexec_file.c | 2 +- arch/arm64/mm/init.c | 5 +++-- drivers/of/fdt.c | 9 +++++---- drivers/of/kexec.c | 9 +++++++++ include/linux/crash_reserve.h | 4 +++- 6 files changed, 22 insertions(+), 9 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 4d0f545fb3ec..52742fab49a9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1119,7 +1119,7 @@ Kernel parameters It will be ignored when crashkernel=3DX,high is not used or memory reserved is below 4G. crashkernel=3Dsize[KMG],cma - [KNL, X86, ppc] Reserve additional crash kernel memory from + [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from CMA. This reservation is usable by the first system's userspace memory and kernel movable allocations (memory balloon, zswap). Pages allocated from this memory range diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index 14e65351133e..d0f73eb3f856 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -43,7 +43,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage *ima= ge) unsigned int arch_get_system_nr_ranges(void) { /* for exclusion of crashkernel region */ - unsigned int nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; + unsigned int nr_ranges =3D 2 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADD= ING; phys_addr_t start, end; u64 i; =20 diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 97987f850a33..227f58522dad 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -96,8 +96,8 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit; =20 static void __init arch_reserve_crashkernel(void) { + unsigned long long crash_base, crash_size, cma_size =3D 0; unsigned long long low_size =3D 0; - unsigned long long crash_base, crash_size; bool high =3D false; int ret; =20 @@ -106,11 +106,12 @@ static void __init arch_reserve_crashkernel(void) =20 ret =3D parse_crashkernel(boot_command_line, memblock_phys_mem_size(), &crash_size, &crash_base, - &low_size, NULL, &high); + &low_size, &cma_size, &high); if (ret) return; =20 reserve_crashkernel_generic(crash_size, crash_base, low_size, high); + reserve_crashkernel_cma(cma_size); } =20 static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 82f7327c59ea..0470acbd1fcf 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -880,11 +880,12 @@ static unsigned long chosen_node_offset =3D -FDT_ERR_= NOTFOUND; /* * The main usage of linux,usable-memory-range is for crash dump kernel. * Originally, the number of usable-memory regions is one. Now there may - * be two regions, low region and high region. - * To make compatibility with existing user-space and older kdump, the low - * region is always the last range of linux,usable-memory-range if exist. + * be 2 + CRASHK_CMA_RANGES_MAX regions, low region, high region and cma + * regions. To make compatibility with existing user-space and older kdump, + * the high and low region are always the first two ranges of + * linux,usable-memory-range if exist. */ -#define MAX_USABLE_RANGES 2 +#define MAX_USABLE_RANGES (2 + CRASHK_CMA_RANGES_MAX) =20 /** * early_init_dt_check_for_usable_mem_range - Decode usable memory range diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c index b6837e299e7f..029903b986cb 100644 --- a/drivers/of/kexec.c +++ b/drivers/of/kexec.c @@ -458,6 +458,15 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage= *image, if (ret) goto out; } + + for (int i =3D 0; i < crashk_cma_cnt; i++) { + ret =3D fdt_appendprop_addrrange(fdt, 0, chosen_node, + "linux,usable-memory-range", + crashk_cma_ranges[i].start, + crashk_cma_ranges[i].end - crashk_cma_ranges[i].start + 1); + if (ret) + goto out; + } #endif } =20 diff --git a/include/linux/crash_reserve.h b/include/linux/crash_reserve.h index f0dc03d94ca2..30864d90d7f5 100644 --- a/include/linux/crash_reserve.h +++ b/include/linux/crash_reserve.h @@ -14,9 +14,11 @@ extern struct resource crashk_res; extern struct resource crashk_low_res; extern struct range crashk_cma_ranges[]; + +#define CRASHK_CMA_RANGES_MAX 4 #if defined(CONFIG_CMA) && defined(CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RES= ERVATION) #define CRASHKERNEL_CMA -#define CRASHKERNEL_CMA_RANGES_MAX 4 +#define CRASHKERNEL_CMA_RANGES_MAX (CRASHK_CMA_RANGES_MAX) extern int crashk_cma_cnt; #else #define crashk_cma_cnt 0 --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CEA03AE1A8; Mon, 1 Jun 2026 09:50:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307415; cv=none; b=RGLpJdpXjCY9Dc51B8W5LeNggbZhdJMzHbEV8eV9dgwLOREW/uz9706222f4skBVVgmC+uZsc6y3y7cohxB3rbl7EwcQ5ipyd2RkideWF7w+cOQc6NFKgJNR2AIFwgytdoEpd4ykfCyR5ZeL+m/DAfJqMJ4QSA2dTvPMOhQWBfc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307415; c=relaxed/simple; bh=fCUrCk6L36YOSminmqL9fNKzYL2iqiHejyxewJzbvPA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Sc/jx3S6QBb6JFfxOo7UPCzIPQMEzRc+ht36VgVy+z4DpDQHasKSPJXRj+wV3sTx708H1zOhdFZUSW8GLqRBAeMQti5/Iywl6IbFylF07mcyu/7EsmYgjXrkaFQwrcF5NSAgLRI3gt5T30K2x86ZWUTDtNYMNEu4JRMo1my5dnM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=r8cHiHGy; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="r8cHiHGy" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=KNI1JgMqQBEclfFkwY59/e9BqHQuiKgtEtSXvTUQWJU=; b=r8cHiHGyBqNA8GiJtVy2v0vJUwde5ED9/AX8LINlxsAvRTEzcnlLFmORy5/N7VHU6h2ia6eAQ oybGrtKUCM+T4199Uk/Ptlb7vaNWxBIfcHdz9XlQJI57tkyXxN7dmqByIfjlj8jwrB2e+CpD0Pf WSrtNGy5FYKGZi5fqh2oRt4= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWc4G54zcb11; Mon, 1 Jun 2026 17:42:04 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 4C35E40569; Mon, 1 Jun 2026 17:50:00 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:49:56 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 22/23] riscv: kexec_file: Add support for crashkernel CMA reservation Date: Mon, 1 Jun 2026 17:48:04 +0800 Message-ID: <20260601094805.2928614-23-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel=3D command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. This allows the kernel to dynamically allocate contiguous memory for crash dumping when needed, rather than permanently reserving a fixed region at boot time. So extend crashkernel CMA reservation support to riscv. The following changes are made to enable CMA reservation: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use, which was already done in of_kexec_alloc_and_setup_fdt(). - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, which was already done in the crash core. Update kernel-parameters.txt to document CMA support for crashkernel on riscv architecture. Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Acked-by: Baoquan He Acked-by: Mike Rapoport (Microsoft) Acked-by: Paul Walmsley # arch/riscv Signed-off-by: Jinjie Ruan --- Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++-------- arch/riscv/kernel/machine_kexec_file.c | 2 +- arch/riscv/mm/init.c | 5 +++-- 3 files changed, 12 insertions(+), 11 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 52742fab49a9..3ff3ddd516cf 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1119,14 +1119,14 @@ Kernel parameters It will be ignored when crashkernel=3DX,high is not used or memory reserved is below 4G. crashkernel=3Dsize[KMG],cma - [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from - CMA. This reservation is usable by the first system's - userspace memory and kernel movable allocations (memory - balloon, zswap). Pages allocated from this memory range - will not be included in the vmcore so this should not - be used if dumping of userspace memory is intended and - it has to be expected that some movable kernel pages - may be missing from the dump. + [KNL, X86, ARM64, RISCV, PPC] Reserve additional crash + kernel memory from CMA. This reservation is usable by + the first system's userspace memory and kernel movable + allocations (memory balloon, zswap). Pages allocated + from this memory range will not be included in the vmcore + so this should not be used if dumping of userspace memory + is intended and it has to be expected that some movable + kernel pages may be missing from the dump. =20 A standard crashkernel reservation, as described above, is still needed to hold the crash kernel and initrd. diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/mac= hine_kexec_file.c index 6e2a6747d187..42d847154e19 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -47,7 +47,7 @@ static int get_nr_ram_ranges_callback(struct resource *re= s, void *arg) unsigned int arch_get_system_nr_ranges(void) { /* For exclusion of crashkernel region */ - unsigned int nr_ranges =3D 2 + CRASH_HOTPLUG_SAFETY_PADDING; + unsigned int nr_ranges =3D 2 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADD= ING; =20 walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback); =20 diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index decd7df40fa4..c848454b8349 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -1295,7 +1295,7 @@ static inline void setup_vm_final(void) */ static void __init arch_reserve_crashkernel(void) { - unsigned long long low_size =3D 0; + unsigned long long low_size =3D 0, cma_size =3D 0; unsigned long long crash_base, crash_size; bool high =3D false; int ret; @@ -1305,11 +1305,12 @@ static void __init arch_reserve_crashkernel(void) =20 ret =3D parse_crashkernel(boot_command_line, memblock_phys_mem_size(), &crash_size, &crash_base, - &low_size, NULL, &high); + &low_size, &cma_size, &high); if (ret) return; =20 reserve_crashkernel_generic(crash_size, crash_base, low_size, high); + reserve_crashkernel_cma(cma_size); } =20 void __init paging_init(void) --=20 2.34.1 From nobody Mon Jun 8 06:38:20 2026 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D27539B958; Mon, 1 Jun 2026 09:50:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307422; cv=none; b=Cq5igCCbmsGANEM65E96rfNcOxrPkgE4TXrZPQJiQHj+U3zfNW8hYL+aXJ2i0j2MexBWYJ7fRMh6AyqyZQ5b72LUOjWTD9N37+6oPI3LJgcBjspDx8jgmu6KrINj8SK4mAIbT6sR62WHtD8WPwOP1d8W7wZ8Yjwl3cALAhMFQOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307422; c=relaxed/simple; bh=a4gMYGQiYhp1KmAYoX19r0tgaPdhdgCwOP9dOP08itQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ht5UvYEq7+kIe8UD0n0hXmhQM/EVjBvFz8ettUBJznbja1hPBhG3l6dMboTs+DfK9Dehmga10QF0v3FjWBjKqpReDVn6u6S33f0UHqnFueYbBCiL8KD0OUwfW7Pmldrvb4IZZ4kPrlPGR0JI7sW9w+R9r32Ti45LyAWjKrEO5Go= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=lGO4jUML; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="lGO4jUML" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=NMfQo98jo8ECVpuOal5Pj3QkE2scVbvFzpqAZff4Fag=; b=lGO4jUMLXh7PUPz2g3M4xRkxm5LnWh5mHdKuAEZ9n+1ROfVyL0Wd+zG8D5OiJA2HGLoHIi0/X HGyRAeGV53vEYZwingSDvcOgh4NugimoAxnxaYD3AmA+oZMHaml2368yocWQK7uBIyGSpKMNEYA oKNI0Qd3ypUn0f7J0s427qI= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4gTTWr5ZSxz1cyQh; Mon, 1 Jun 2026 17:42:16 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 420A040539; Mon, 1 Jun 2026 17:50:04 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 1 Jun 2026 17:50:00 +0800 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Subject: [PATCH v15 23/23] arm64: crash: Add crash hotplug support Date: Mon, 1 Jun 2026 17:48:05 +0800 Message-ID: <20260601094805.2928614-24-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260601094805.2928614-1-ruanjinjie@huawei.com> References: <20260601094805.2928614-1-ruanjinjie@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" Due to CPU/Memory hotplug or online/offline events, the elfcorehdr (which describes the CPUs and memory of the crashed kernel) of kdump image becomes outdated. Consequently, attempting dump collection with an outdated elfcorehdr can lead to inaccurate dump collection. The current solution to address the above issue involves monitoring the CPU/Memory add/remove events in userspace using udev rules and whenever there are changes in CPU and memory resources, the entire kdump image is loaded again. The kdump image includes kernel, initrd, elfcorehdr, FDT, purgatory. Given that only elfcorehdr gets outdated due to CPU/Memory add/remove events, reloading the entire kdump image is inefficient. More importantly, kdump remains inactive for a substantial amount of time until the kdump reload completes. To address the aforementioned issue, commit 247262756121 ("crash: add generic infrastructure for crash hotplug support") added a generic infrastructure that allows architectures to selectively update the kdump image component during CPU or memory add/remove events within the kernel itself. In the event of a CPU or memory add/remove events, the generic crash hotplug event handler, crash_handle_hotplug_event(), is triggered. It then acquires the necessary locks to update the kdump image and invokes the architecture-specific crash hotplug handler, arch_crash_handle_hotplug_event(), to update the required kdump image components. [1] has supported virtual CPU hotplug in virtual machines for ARM64, allowing vCPUs to be added or removed at runtime to meet Kubernetes demands. On ARM64, only memory add/remove events are handled. Here's why: 1. Physical CPU hotplug: Not supported on ARM64 hardware. 2. ACPI vCPU hotplug (KVM virtual machine): - vCPU hotplug is implemented as a static firmware policy where all possible vCPUs are pre-described in the MADT table at boot. - The vCPU status will be automatically updated after vCPU hotplug. - No FDT or elfcorehdr update needed. 3. Device tree booted Virtual Machine vCPU hotplug: - The elfcorehdr is built using for_each_possible_cpu(), so it already includes all possible CPUs and doesn't need updates. For memory add/remove events, the elfcorehdr is updated to reflect the current memory layout. This patch adds the ARCH_SUPPORTS_CRASH_HOTPLUG config option and implements: - arch_crash_hotplug_support(): Check if hotplug update is supported - arch_crash_get_elfcorehdr_size(): Return elfcorehdr buffer size - arch_crash_handle_hotplug_event(): Handle memory hotplug events This follows the same approach as x86 commit ea53ad9cf73b ("x86/crash: add x86 crash hotplug support") and powerpc commit b741092d5976 ("powerpc/crash: add crash CPU hotplug support") and commit 849599b702ef ("powerpc/crash: add crash memory hotplug support"). The test is based on the following QEMU version: https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2 Replace your '-smp' argument with something like: | -smp cpus=3D1,maxcpus=3D3,cores=3D3,threads=3D1,sockets=3D1 then feed the following to the Qemu montior to hotplug vCPU; | (qemu) device_add driver=3Dhost-arm-cpu,core-id=3D1,id=3Dcpu1 | (qemu) device_del cpu1 feed the following to the Qemu montior to hotplug memory; | (qemu) object_add memory-backend-ram,id=3Dmem1,size=3D256M | (qemu) device_add pc-dimm,id=3Ddimm1,memdev=3Dmem1 | (qemu) device_del dimm1 The qemu startup configuration is as follows: qemu-system-aarch64 \ -M virt,gic-version=3D3,acpi=3Don,highmem=3Don \ -enable-kvm \ -cpu host \ -kernel Image \ -smp cpus=3D1,maxcpus=3D3,cores=3D3,threads=3D1,sockets=3D1 \ -bios /usr/share/edk2/aarch64/QEMU_EFI.fd \ -m 2G,slots=3D64,maxmem=3D16G \ -nographic \ -no-reboot \ -device virtio-rng-pci \ -append "root=3D/dev/vda rw console=3DttyAMA0 kgdboc=3DttyAMA0,115200 \ earlycon acpi=3Don crashkernel=3D512M" \ -drive if=3Dnone,file=3Dimages/rootfs.ext4,format=3Draw,id=3Dhd0 \ -device virtio-blk-device,drive=3Dhd0 \ There are two system calls, `kexec_file_load` and `kexec_load`, used to load the kdump image. Only kexec_file_load syscall way is tested now. Cc: Catalin Marinas Cc: Will Deacon Cc: Baoquan He Cc: "Mike Rapoport (Microsoft)" Cc: Andrew Morton Cc: Breno Leitao Cc: Kees Cook [1]: https://lore.kernel.org/all/20240529133446.28446-1-Jonathan.Cameron@hu= awei.com/ Signed-off-by: Jinjie Ruan --- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/kexec.h | 13 +++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/crash.c | 152 +++++++++++++++++++++++++ arch/arm64/kernel/kexec_image.c | 21 +++- arch/arm64/kernel/machine_kexec_file.c | 40 ++----- 6 files changed, 195 insertions(+), 36 deletions(-) create mode 100644 arch/arm64/kernel/crash.c diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fe60738e5943..9091c67e1cc2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1609,6 +1609,9 @@ config ARCH_DEFAULT_CRASH_DUMP config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION def_bool CRASH_RESERVE =20 +config ARCH_SUPPORTS_CRASH_HOTPLUG + def_bool y + config TRANS_TABLE def_bool y depends on HIBERNATION || KEXEC_CORE diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h index 892e5bebda95..4f3d4fc2807e 100644 --- a/arch/arm64/include/asm/kexec.h +++ b/arch/arm64/include/asm/kexec.h @@ -130,6 +130,19 @@ extern int load_other_segments(struct kimage *image, char *cmdline); #endif =20 +#ifdef CONFIG_CRASH_HOTPLUG +#define pnum_hdr_sz(pnum) ((pnum) * sizeof(Elf64_Phdr) + sizeof(Elf64_Ehdr= )) + +void arch_crash_handle_hotplug_event(struct kimage *image, void *arg); +#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event + +int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_f= lags); +#define arch_crash_hotplug_support arch_crash_hotplug_support + +unsigned int arch_crash_get_elfcorehdr_size(void); +#define crash_get_elfcorehdr_size arch_crash_get_elfcorehdr_size +#endif + #endif /* __ASSEMBLER__ */ =20 #endif diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index 74b76bb70452..0625422fc528 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -64,7 +64,7 @@ obj-$(CONFIG_KEXEC_CORE) +=3D machine_kexec.o relocate_k= ernel.o \ obj-$(CONFIG_KEXEC_FILE) +=3D machine_kexec_file.o kexec_image.o obj-$(CONFIG_ARM64_RELOC_TEST) +=3D arm64-reloc-test.o arm64-reloc-test-y :=3D reloc_test_core.o reloc_test_syms.o -obj-$(CONFIG_CRASH_DUMP) +=3D crash_dump.o +obj-$(CONFIG_CRASH_DUMP) +=3D crash_dump.o crash.o obj-$(CONFIG_VMCORE_INFO) +=3D vmcore_info.o obj-$(CONFIG_ARM_SDE_INTERFACE) +=3D sdei.o obj-$(CONFIG_ARM64_PTR_AUTH) +=3D pointer_auth.o diff --git a/arch/arm64/kernel/crash.c b/arch/arm64/kernel/crash.c new file mode 100644 index 000000000000..5882b9b5a90e --- /dev/null +++ b/arch/arm64/kernel/crash.c @@ -0,0 +1,152 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Architecture specific functions for kexec based crash dumps. + */ + +#define pr_fmt(fmt) "crash hp: " fmt + +#include +#include +#include +#include +#include +#include + +#include + +#if defined(CONFIG_KEXEC_FILE) || defined(CONFIG_CRASH_HOTPLUG) +unsigned int arch_get_system_nr_ranges(void) +{ + /* for exclusion of crashkernel region */ + unsigned int nr_ranges =3D 2 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADD= ING; + phys_addr_t start, end; + u64 i; + + for_each_mem_range(i, &start, &end) + nr_ranges++; + + return nr_ranges; +} + +int arch_crash_populate_cmem(struct crash_mem *cmem) +{ + phys_addr_t start, end; + u64 i; + + for_each_mem_range(i, &start, &end) { + if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) + return -EAGAIN; + + cmem->ranges[cmem->nr_ranges].start =3D start; + cmem->ranges[cmem->nr_ranges].end =3D end - 1; + cmem->nr_ranges++; + } + + return 0; +} +#endif + +#ifdef CONFIG_CRASH_HOTPLUG +int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_f= lags) +{ +#ifdef CONFIG_KEXEC_FILE + if (image->file_mode) + return 1; +#endif + /* + * For kexec_load syscall, crash hotplug support requires + * KEXEC_CRASH_HOTPLUG_SUPPORT flag to be passed by userspace. + */ + return kexec_flags & KEXEC_CRASH_HOTPLUG_SUPPORT; +} + +unsigned int arch_crash_get_elfcorehdr_size(void) +{ + unsigned int phdr_cnt; + + /* A program header for possible CPUs, vmcoreinfo and kernel_map */ + phdr_cnt =3D 2 + num_possible_cpus(); + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) + phdr_cnt +=3D CONFIG_CRASH_MAX_MEMORY_RANGES; + + return pnum_hdr_sz(phdr_cnt); +} + +/** + * update_crash_elfcorehdr() - Recreate the elfcorehdr and replace it with= old + * elfcorehdr in the kexec segment array. + * @image: the active struct kimage + */ +static void update_crash_elfcorehdr(struct kimage *image) +{ + void *elfbuf =3D NULL, *old_elfcorehdr; + unsigned long mem, memsz; + unsigned long elfsz =3D 0; + + /* + * Create the new elfcorehdr reflecting the changes to CPU and/or + * memory resources. + */ + if (crash_prepare_headers(true, &elfbuf, &elfsz, NULL)) { + pr_err("unable to create new elfcorehdr"); + goto out; + } + + /* + * Obtain address and size of the elfcorehdr segment, and + * check it against the new elfcorehdr buffer. + */ + mem =3D image->segment[image->elfcorehdr_index].mem; + memsz =3D image->segment[image->elfcorehdr_index].memsz; + if (elfsz > memsz) { + pr_err("update elfcorehdr elfsz %lu > memsz %lu", + elfsz, memsz); + goto out; + } + + /* + * Copy new elfcorehdr over the old elfcorehdr at destination. + */ + old_elfcorehdr =3D (void *)__va(mem); + if (!old_elfcorehdr) { + pr_err("mapping elfcorehdr segment failed\n"); + goto out; + } + + /* + * Temporarily invalidate the crash image while the + * elfcorehdr is updated. + */ + xchg(&kexec_crash_image, NULL); + memcpy((void *)old_elfcorehdr, elfbuf, elfsz); + dcache_clean_inval_poc((unsigned long)old_elfcorehdr, + (unsigned long)old_elfcorehdr + elfsz); + xchg(&kexec_crash_image, image); + pr_debug("updated elfcorehdr\n"); + +out: + vfree(elfbuf); +} + +/** + * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes + * @image: a pointer to kexec_crash_image + * @arg: struct memory_notify handler for memory hotplug case and + * NULL for CPU hotplug case. + * + * Update the kdump image based on the type of hotplug event: + * - CPU add and remove: No action is needed. + * - Memory add/remove: Update the elfcorehdr to reflect the current memor= y layout. + * + * Prepare the new elfcorehdr and replace the existing elfcorehdr. + */ +void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) +{ + if ((image->file_mode || image->elfcorehdr_updated) && + ((image->hp_action =3D=3D KEXEC_CRASH_HP_ADD_CPU) || + (image->hp_action =3D=3D KEXEC_CRASH_HP_REMOVE_CPU))) + return; + + update_crash_elfcorehdr(image); +} +#endif /* CONFIG_CRASH_HOTPLUG */ diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_imag= e.c index 93c36a3aa618..21f38de7a8b6 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -8,6 +8,7 @@ =20 #define pr_fmt(fmt) "kexec_file(Image): " fmt =20 +#include #include #include #include @@ -92,16 +93,32 @@ static void *image_load(struct kimage *image, #ifdef CONFIG_CRASH_DUMP if (image->type =3D=3D KEXEC_TYPE_CRASH) { /* load elf core header */ - unsigned long headers_sz; + unsigned long headers_sz, pnum =3D 0; void *headers; =20 - ret =3D crash_prepare_headers(true, &headers, &headers_sz, NULL); + ret =3D crash_prepare_headers(true, &headers, &headers_sz, &pnum); if (ret) { pr_err("Preparing elf core header failed\n"); return ERR_PTR(ret); } image->elf_headers =3D headers; image->elf_headers_sz =3D headers_sz; + +#ifdef CONFIG_CRASH_HOTPLUG + /* + * The elfcorehdr segment size accounts for VMCOREINFO, kernel_map + * maximum CPUs and maximum memory ranges. + */ + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) + pnum =3D 2 + num_possible_cpus() + CONFIG_CRASH_MAX_MEMORY_RANGES; + else + pnum +=3D 2 + num_possible_cpus(); + + if (pnum < (unsigned long)PN_XNUM) + image->elf_headers_sz =3D max(pnum_hdr_sz(pnum), headers_sz); + else + pr_err("number of Phdrs %lu exceeds max\n", pnum); +#endif } #endif =20 diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/mac= hine_kexec_file.c index d0f73eb3f856..0016001f4d00 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -10,11 +10,11 @@ =20 #define pr_fmt(fmt) "kexec_file: " fmt =20 +#include #include #include #include #include -#include #include #include #include @@ -39,38 +39,6 @@ int arch_kimage_file_post_load_cleanup(struct kimage *im= age) return kexec_image_post_load_cleanup_default(image); } =20 -#ifdef CONFIG_CRASH_DUMP -unsigned int arch_get_system_nr_ranges(void) -{ - /* for exclusion of crashkernel region */ - unsigned int nr_ranges =3D 2 + crashk_cma_cnt + CRASH_HOTPLUG_SAFETY_PADD= ING; - phys_addr_t start, end; - u64 i; - - for_each_mem_range(i, &start, &end) - nr_ranges++; - - return nr_ranges; -} - -int arch_crash_populate_cmem(struct crash_mem *cmem) -{ - phys_addr_t start, end; - u64 i; - - for_each_mem_range(i, &start, &end) { - if (unlikely(cmem->nr_ranges >=3D cmem->max_nr_ranges)) - return -EAGAIN; - - cmem->ranges[cmem->nr_ranges].start =3D start; - cmem->ranges[cmem->nr_ranges].end =3D end - 1; - cmem->nr_ranges++; - } - - return 0; -} -#endif - /* * Tries to add the initrd and DTB to the image. If it is not possible to = find * valid locations, this function will undo changes to the image and retur= n non @@ -98,6 +66,12 @@ int load_other_segments(struct kimage *image, kbuf.bufsz =3D image->elf_headers_sz; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; kbuf.memsz =3D image->elf_headers_sz; + +#ifdef CONFIG_CRASH_HOTPLUG + if (image->elf_headers_sz < pnum_hdr_sz(PN_XNUM)) + image->elfcorehdr_index =3D image->nr_segments; +#endif + kbuf.buf_align =3D SZ_64K; /* largest supported page size */ kbuf.buf_max =3D ULONG_MAX; kbuf.top_down =3D true; --=20 2.34.1