From nobody Sat Sep 26 11:01:43 2026 Received: from sg-3-27.ptr.tlmpb.com (sg-3-27.ptr.tlmpb.com [101.45.255.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E51930C606 for ; Wed, 2 Sep 2026 09:09:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=101.45.255.27 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340190; cv=none; b=VTbucbp0DjZGb2VHVHs23lv/xO39iJZ8Q3hZTcMOEuizlQNR3I5qPnYEaHgzbe+rK9MfOfr9GKRC8s/gL6PAVbPWSta+v+M5mpCPxKFoVSj5mPVCT0A7V29xAFBANBvuNnvaHc754jXQu4yxygZv+3l+zoXRjwarmqouW+g6LLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340190; c=relaxed/simple; bh=xDcl2IzrUmdFBAk/D7YGSp5x4q5rTB0jmTqOmetd1cY=; h=To:Cc:Content-Type:From:Mime-Version:References:Subject: In-Reply-To:Date:Message-Id; b=VXiIUQq3X2l+bJGR+pwRM1FppohQ8ZWpNsFywXuddLKWQlOzJmmbFR8XGI83mrbqMWRyWA/fCBaLaaO7MMEKTWE0EVwCVHY+Q1FXdsoCKH2C/bv5RAXt/bpVGLg5DpcHr2EcvvmO435l0I/nBN0XOb1dkODNsQoJIrnupRo0KAc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com; spf=pass smtp.mailfrom=picoheart.com; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b=HWXaBiVj; arc=none smtp.client-ip=101.45.255.27 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=picoheart.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b="HWXaBiVj" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1788340138; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=C50quJcwO5XVGyYBcmo1hG+o10dNM+2wEjOwukPtWwY=; b=HWXaBiVjdiuaIE60TfJ0uL5CZSkuKEf91ukIJA48qPEUONASvLZW1AbDXyUtES6gVLqyKc 9kunO4rCl25aCi3e7TJJrYjhsGMXjM0m+FCdnC4/H1yEGz8Z2KAq52NL97PYAl6URbiTKP J6MfXxW0vs7hoRRHG5bjMvMiEZRH9rNllujVlEIHtTZjSxHSSujLv321cC4Gcu5X0wEoP7 TnM4XptPqV5hh+83MBuMO1B1w2TyD93jImZO8eRMGsikujtkoDLMw5z1vCbVyp0ZSmZ3KW zcz9zi0ygH61yJ6Q8wN1CqL4/onDBDsBRJG1fIZDEf/wyr+wzGlJ7gZjDA932Q== Received: from 5CG30262N9-QAP.localdomain ([120.234.49.250]) by smtp.feishu.cn with ESMTPS; Wed, 02 Sep 2026 17:08:55 +0800 To: , , Cc: , , , , , , , , , , , , , , Content-Transfer-Encoding: quoted-printable From: "Yufan Dou" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260902090850.2601-1-douyufan@picoheart.com> Subject: [PATCH RESEND 1/3] riscv: kexec_file: constrain extra segments to the Sv39 direct map X-Mailer: git-send-email 2.53.0 X-Lms-Return-Path: X-Original-From: Yufan Dou In-Reply-To: <20260902090850.2601-1-douyufan@picoheart.com> Date: Wed, 2 Sep 2026 17:08:48 +0800 Message-Id: <20260902090850.2601-2-douyufan@picoheart.com> Content-Type: text/plain; charset="utf-8" When an Sv48 or Sv57 kernel loads an Sv39 kernel, top-down allocation can place the initrd and other extra segments above the direct-map range supported by the next kernel. During early boot, setup_bootmem() limits usable memory to phys_ram_base + KERN_VIRT_SIZE. Any segment placed above the Sv39 limit is therefore unreachable by the next kernel. In particular, an initrd outside this range is disabled during boot. The max_low_pfn limit only reflects the direct map of the loading kernel and is insufficient when the next kernel uses a narrower address space. The paging mode of the next kernel is not known at load time, so apply the Sv39 limit unconditionally. On a machine with more than 128 GiB this also constrains a next kernel that would run in Sv48 or Sv57. Limit extra segment placement to the smaller of the loading kernel's direct-map limit and the end of the Sv39 direct map. The next kernel derives its direct map from the start of the memory it is given, which is the crash kernel region for a crash image, so use that region as the base in that case. A NOMMU kernel has no direct map and keeps the limit of the loading kernel. Fixes: b67a1ee0db00 ("riscv: kexec_file: Constrain segment placement to dir= ect map") Co-developed-by: Yicong Yang Signed-off-by: Yicong Yang Signed-off-by: Yufan Dou --- arch/riscv/kernel/machine_kexec_file.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/mac= hine_kexec_file.c index 26cd2a8bd0cd..15a3c180c558 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -239,6 +239,29 @@ int arch_kexec_apply_relocations_add(struct purgatory_= info *pi, } =20 =20 +/* + * The next kernel may run in Sv39 even when the current kernel runs in Sv= 48 or + * Sv57, in which case the direct map of the next kernel is narrower. Any + * segment placed above it is unreachable by the next kernel during early = boot. + * The next kernel derives its direct map from the start of the memory it = is + * given, which is the crash kernel region for a crash image. A NOMMU kern= el + * has no direct map, so only the limit of the current kernel applies. + */ +static unsigned long kexec_segment_limit(struct kimage *image) +{ + unsigned long limit =3D PFN_PHYS(max_low_pfn); +#ifdef CONFIG_MMU + unsigned long base =3D phys_ram_base; + +#ifdef CONFIG_CRASH_DUMP + if (image->type =3D=3D KEXEC_TYPE_CRASH) + base =3D crashk_res.start; +#endif + limit =3D min(limit, base + BIT(VA_BITS_SV39 - 2) - 1); +#endif + return limit; +} + int load_extra_segments(struct kimage *image, unsigned long kernel_start, unsigned long kernel_len, char *initrd, unsigned long initrd_len, char *cmdline, @@ -252,7 +275,7 @@ int load_extra_segments(struct kimage *image, unsigned = long kernel_start, =20 kbuf.image =3D image; kbuf.buf_min =3D kernel_start + kernel_len; - kbuf.buf_max =3D PFN_PHYS(max_low_pfn); + kbuf.buf_max =3D kexec_segment_limit(image); =20 #ifdef CONFIG_CRASH_DUMP /* Add elfcorehdr */ --=20 2.34.1 From nobody Sat Sep 26 11:01:43 2026 Received: from va-2-39.ptr.blmpb.com (va-2-39.ptr.blmpb.com [209.127.231.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F290E409620 for ; Wed, 2 Sep 2026 09:09:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.39 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340154; cv=none; b=tRZB/LdXu7EMH05dzkxBV3anHudHsm921KYeceR7SMqMqGrQtt91BtMso87j9LXqe1dBtykGKWYyFi9P2qbtOFXOYRdlcRdc6QMxOZ0/Y4T8MiQEfyxhOlndhAIbtDp4VoDYJ94E8oZtaHaT2qlkIQdwWOONUZTESVGZ4BXaXyE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340154; c=relaxed/simple; bh=DX0h9Kv8RfaRB4Jkrya9CrXRZqkgLHqMm8No277bvSU=; h=From:References:Message-Id:In-Reply-To:Cc:Subject:Mime-Version: Content-Type:To:Date; b=DwugN1jbrpJz/+KQs5gSCjf3H13N+6eh0+9+lTPabC7QKvQbqgFu2/hti5DLxTp7t7KfmcDBHWa8S1H8fd188p9U1es10uWe/P406Qv0tVb2CROo/qd2I5JDcGvQoT9241VzCIQhHF4VWUKNVKERA+ObqL10FIr3jCgLilUnAyg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com; spf=pass smtp.mailfrom=picoheart.com; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b=rdkWWHNd; arc=none smtp.client-ip=209.127.231.39 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=picoheart.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b="rdkWWHNd" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1788340141; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=aUR1yoU4JOYPKs/rMqqJfgyInNDV//hmTuzZfbk6yls=; b=rdkWWHNdH94aMaglnZ8RSidXMbenbGTGMW+ZAVXi6x4WVscyo12myfk5LHX8RFhOYHoA02 olnSMdRMD5Mr7EDV0clW27QbVYsYL6x7Gs/NtRC4MJemOMeu+FqTTCui6/VOs38Ngz1ooa ofzdj0VZlwo8kpbcqJL+Co2k45j/8VbT3WVzggolczE8DyBIDqKFwI2eA0czkntKraQkgM Vxlj8JH6tqGNoyQoICxul50CT+9pqG34ZONPmomNGrnfJ0JxGG4pqppGDVFJ8QMUI7M74A VC2t9aZGbIGI0IuUCcC7BeFSPkp2uXMZqxUCk+F0S55fPzW2MGf6cNsA+9jbZw== From: "Yufan Dou" References: <20260902090850.2601-1-douyufan@picoheart.com> Message-Id: <20260902090850.2601-3-douyufan@picoheart.com> Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260902090850.2601-1-douyufan@picoheart.com> Cc: , , , , , , , , , , , , , , Subject: [PATCH RESEND 2/3] riscv: kexec_file: size the ELF placement search by the load extent Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Received: from 5CG30262N9-QAP.localdomain ([120.234.49.250]) by smtp.feishu.cn with ESMTPS; Wed, 02 Sep 2026 17:08:58 +0800 X-Original-From: Yufan Dou To: , , Date: Wed, 2 Sep 2026 17:08:49 +0800 X-Mailer: git-send-email 2.53.0 X-Lms-Return-Path: Content-Type: text/plain; charset="utf-8" elf_find_pbase() searches for a memory hole to place the whole kernel image, and the segments are then added at fixed addresses derived from the base it returns. kexec_add_buffer() skips the memory hole check for a segment whose address is already known. The search is sized by the length of the ELF file, which does not reflect the extent the image occupies in memory: a PT_LOAD segment can have a memory size larger than its file size, so a stripped vmlinux can end up needing more memory than the file length accounts for. The tail of the image is then placed without any check that the memory is available. Size the search by the extent between the lowest and the highest physical address of the PT_LOAD segments instead, and drop the now unused kernel_len argument. Fixes: 6261586e0c91 ("RISC-V: Add kexec_file support") Cc: stable@vger.kernel.org Co-developed-by: Yicong Yang Signed-off-by: Yicong Yang Signed-off-by: Yufan Dou --- arch/riscv/kernel/kexec_elf.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/arch/riscv/kernel/kexec_elf.c b/arch/riscv/kernel/kexec_elf.c index 3e9a32acb8f2..d84548f9d289 100644 --- a/arch/riscv/kernel/kexec_elf.c +++ b/arch/riscv/kernel/kexec_elf.c @@ -54,9 +54,9 @@ static int riscv_kexec_elf_load(struct kimage *image, str= uct elfhdr *ehdr, * Go through the available phsyical memory regions and find one that hold * an image of the specified size. */ -static int elf_find_pbase(struct kimage *image, unsigned long kernel_len, - struct elfhdr *ehdr, struct kexec_elf_info *elf_info, - unsigned long *old_pbase, unsigned long *new_pbase) +static int elf_find_pbase(struct kimage *image, struct elfhdr *ehdr, + struct kexec_elf_info *elf_info, unsigned long *old_pbase, + unsigned long *new_pbase) { int i; int ret; @@ -64,6 +64,7 @@ static int elf_find_pbase(struct kimage *image, unsigned = long kernel_len, const struct elf_phdr *phdr; unsigned long lowest_paddr =3D ULONG_MAX; unsigned long lowest_vaddr =3D ULONG_MAX; + unsigned long highest_paddr =3D 0; =20 for (i =3D 0; i < ehdr->e_phnum; i++) { phdr =3D &elf_info->proghdrs[i]; @@ -75,6 +76,9 @@ static int elf_find_pbase(struct kimage *image, unsigned = long kernel_len, =20 if (lowest_vaddr > phdr->p_vaddr) lowest_vaddr =3D phdr->p_vaddr; + + highest_paddr =3D max(highest_paddr, + (unsigned long)(phdr->p_paddr + phdr->p_memsz)); } =20 kbuf.image =3D image; @@ -88,7 +92,12 @@ static int elf_find_pbase(struct kimage *image, unsigned= long kernel_len, */ kbuf.buf_align =3D PMD_SIZE; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; - kbuf.memsz =3D ALIGN(kernel_len, PAGE_SIZE); + /* + * The segments are added at fixed addresses later on, which makes + * kexec_add_buffer() skip the memory hole check, so the range searched + * here has to cover the whole extent the image occupies in memory. + */ + kbuf.memsz =3D ALIGN(highest_paddr - lowest_paddr, PAGE_SIZE); kbuf.cma =3D NULL; kbuf.top_down =3D false; ret =3D arch_kexec_locate_mem_hole(&kbuf); @@ -115,8 +124,8 @@ static void *elf_kexec_load(struct kimage *image, char = *kernel_buf, if (ret) return ERR_PTR(ret); =20 - ret =3D elf_find_pbase(image, kernel_len, &ehdr, &elf_info, - &old_kernel_pbase, &new_kernel_pbase); + ret =3D elf_find_pbase(image, &ehdr, &elf_info, &old_kernel_pbase, + &new_kernel_pbase); if (ret) goto out; =20 --=20 2.34.1 From nobody Sat Sep 26 11:01:43 2026 Received: from va-2-35.ptr.blmpb.com (va-2-35.ptr.blmpb.com [209.127.231.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FDB54CCDFC for ; Wed, 2 Sep 2026 09:09:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.35 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340151; cv=none; b=OELgwpWO3G15oHLQPd1R1l+aqxYnaQnpzQ7GVGLsC/mCJO3qZTNvy5J5TdV0R0ccHx/1yFAz93raTlru6KQXGJ+dhxWXyyNnONJatwkK0b8fA2RRRO3xASUaJu+p55dzMgHVaHeGYJLEjHKpkf9tC7m4PCpcfMK1N4xj0tKgWz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788340151; c=relaxed/simple; bh=pD+9laa4E7WkYT99IPB3WFVAXsL8rzxMBi3kdhtqGpQ=; h=Cc:Date:Message-Id:References:Subject:From:Content-Type:To: Mime-Version:In-Reply-To; b=qqhu1UyxELen0uLtD+DdlWXb6TIswUfZeouPHtJhRwsbrq3eeHeMncImVk8uTvPTEmS85xF9XdWUGCmKDaRfs8ZyPkeDaGbAtHqRIht2hZPpqWA1mns9VeqE3l0kiZAksSdHcBhmwVyOq2YSZnciEtDwqvy/pPQMlE8faUHUn+Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com; spf=pass smtp.mailfrom=picoheart.com; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b=AtkO+zDb; arc=none smtp.client-ip=209.127.231.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=picoheart.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=picoheart.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=picoheart.com header.i=@picoheart.com header.b="AtkO+zDb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1788340144; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=lfe3yVyViIS9QqUrO1FybHOjTXn3fmtNC6AuZnCPPzk=; b=AtkO+zDbwLHbqHZ4a7vKzChKqTVswWTXORYE3jIgxNovZnRz55nVPtRftH57Lbz0sNl59j blBYHXhzARNqmfe0ybj3M04bBQdK2MnjIfPAk6S5SgxVznRVLr3G100s6Be+rfLt4N6NGx DVJJlMWHXUFnvHvRnv1fMlNqr3brTUR7hQuPh8j7uLoZgtpZb4g1U21TpmVgsXgpH03aJI H+CtdA20moZKwI7WgVRioswgv4VUG3/COD+MOisA/z1rlTJk6IyW5Rft3ZkujJgiv/2uN+ AkdmehHW4dqMSLZSuYirgRHJ9Fx5TNDI9XxwToWSoihXaDCnNHWFh/dUDwFzSg== Cc: , , , , , , , , , , , , , , Date: Wed, 2 Sep 2026 17:08:50 +0800 Message-Id: <20260902090850.2601-4-douyufan@picoheart.com> References: <20260902090850.2601-1-douyufan@picoheart.com> Subject: [PATCH RESEND 3/3] riscv: kexec: reserve the PMD-aligned kernel image range X-Lms-Return-Path: Content-Transfer-Encoding: quoted-printable From: "Yufan Dou" X-Original-From: Yufan Dou X-Mailer: git-send-email 2.53.0 To: , , Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Received: from 5CG30262N9-QAP.localdomain ([120.234.49.250]) by smtp.feishu.cn with ESMTPS; Wed, 02 Sep 2026 17:09:01 +0800 In-Reply-To: <20260902090850.2601-1-douyufan@picoheart.com> Content-Type: text/plain; charset="utf-8" When strict kernel permissions are enabled, the next kernel extends its image reservation from _start to the PMD-aligned address following _end. If kexec only reserves the exact image range, a later segment can be placed in this aligned tail and overlap the next kernel's reservation. For a flat Image, extend the decoded image size to the next PMD boundary. An ELF image contains multiple PT_LOAD segments. Extending every segment can make an intermediate segment overlap the following one. Find the PT_LOAD segment with the highest physical end address and extend only that segment to the next PMD boundary. Align the extent searched by elf_find_pbase() as well, so that the expanded tail stays within the range validated against the available memory. This reserves the range expected by the next kernel without changing the layout of intermediate ELF segments. Fixes: 6261586e0c91 ("RISC-V: Add kexec_file support") Fixes: 809a11eea8e8 ("riscv: kexec_file: Support loading Image binary file") Cc: stable@vger.kernel.org Co-developed-by: Yicong Yang Signed-off-by: Yicong Yang Signed-off-by: Yufan Dou --- arch/riscv/kernel/kexec_elf.c | 21 +++++++++++++++++++-- arch/riscv/kernel/kexec_image.c | 7 ++++++- 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/kexec_elf.c b/arch/riscv/kernel/kexec_elf.c index d84548f9d289..da5679bf1d0c 100644 --- a/arch/riscv/kernel/kexec_elf.c +++ b/arch/riscv/kernel/kexec_elf.c @@ -28,6 +28,15 @@ static int riscv_kexec_elf_load(struct kimage *image, st= ruct elfhdr *ehdr, int ret =3D 0; struct kexec_buf kbuf =3D {}; const struct elf_phdr *phdr; + unsigned long highest_paddr =3D 0; + + /* Find the highest physical end address of the kernel image. */ + for (i =3D 0; i < ehdr->e_phnum; i++) { + phdr =3D &elf_info->proghdrs[i]; + if (phdr->p_type =3D=3D PT_LOAD) + highest_paddr =3D max(highest_paddr, + (unsigned long)(phdr->p_paddr + phdr->p_memsz)); + } =20 kbuf.image =3D image; =20 @@ -41,6 +50,13 @@ static int riscv_kexec_elf_load(struct kimage *image, st= ruct elfhdr *ehdr, kbuf.buf_align =3D phdr->p_align; kbuf.mem =3D phdr->p_paddr - old_pbase + new_pbase; kbuf.memsz =3D phdr->p_memsz; + /* + * The next kernel aligns its image reservation on PMD_SIZE, as + * explained by a comment in setup_bootmem(). Reserve that tail + * so subsequent segments do not overlap it. + */ + if (phdr->p_paddr + phdr->p_memsz =3D=3D highest_paddr) + kbuf.memsz =3D ALIGN(kbuf.mem + phdr->p_memsz, PMD_SIZE) - kbuf.mem; kbuf.top_down =3D false; ret =3D kexec_add_buffer(&kbuf); if (ret) @@ -95,9 +111,10 @@ static int elf_find_pbase(struct kimage *image, struct = elfhdr *ehdr, /* * The segments are added at fixed addresses later on, which makes * kexec_add_buffer() skip the memory hole check, so the range searched - * here has to cover the whole extent the image occupies in memory. + * here has to cover the whole extent the image occupies in memory, + * including the PMD-aligned tail of the last segment. */ - kbuf.memsz =3D ALIGN(highest_paddr - lowest_paddr, PAGE_SIZE); + kbuf.memsz =3D ALIGN(highest_paddr - lowest_paddr, PMD_SIZE); kbuf.cma =3D NULL; kbuf.top_down =3D false; ret =3D arch_kexec_locate_mem_hole(&kbuf); diff --git a/arch/riscv/kernel/kexec_image.c b/arch/riscv/kernel/kexec_imag= e.c index 51dc89259f16..52678b3044fd 100644 --- a/arch/riscv/kernel/kexec_image.c +++ b/arch/riscv/kernel/kexec_image.c @@ -69,7 +69,12 @@ static void *image_load(struct kimage *image, kbuf.buffer =3D kernel; kbuf.bufsz =3D kernel_len; kbuf.mem =3D KEXEC_BUF_MEM_UNKNOWN; - kbuf.memsz =3D le64_to_cpu(h->image_size); + /* + * The next kernel aligns its image reservation on PMD_SIZE, as + * explained by a comment in setup_bootmem(). Reserve that tail so + * subsequent segments do not overlap it. + */ + kbuf.memsz =3D ALIGN(le64_to_cpu(h->image_size), PMD_SIZE); kbuf.buf_align =3D le64_to_cpu(h->text_offset); =20 ret =3D kexec_add_buffer(&kbuf); --=20 2.34.1