From nobody Fri Oct 2 01:55:57 2026 Received: from va-2-54.ptr.blmpb.com (va-2-54.ptr.blmpb.com [209.127.231.54]) (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 AF0AC261B70 for ; Thu, 6 Aug 2026 07:23:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000990; cv=none; b=DObUwYMOTSTtSqdqBMZuq0P2bO+a+bUlWt7SJquRwnXf4nkSM6ihI5eSV8kJ754IZM4PUgoQfugBhBm8bRhGvV3lTXjwtKnPjZsopBsocpA5V0SOjjA+qy0/Gyn7SKe+rqk4SsMLrFRvR0RUxzbyrU4970/RmjSzSEjjEO+KGg0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000990; c=relaxed/simple; bh=Tsk79chBVdvAC6QpE6HcaxKpHzYguPa/15QZ9AUsdAQ=; h=From:To:Cc:Mime-Version:References:In-Reply-To:Content-Type: Subject:Date:Message-Id; b=IzxO33RxBFbkUDLTVtL92mreUhP7J6JgDYqU03scM4s0HhTSTtKYHK2GyFoms9U+zYaRZgos7smv9VWTLrae56PMFM2TwfKrOVOE5x4wAUcNw5pQppRd07pogOloJehBW+I0segtfCEH/NebPwycq6eAiAL5GiNSDv2eh12CBi4= 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=dk97uCC9; arc=none smtp.client-ip=209.127.231.54 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="dk97uCC9" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1786000982; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=JUHY1QAqG33QM0NaFSsWSJNmlLEjxSrnYIyZMVYmaaI=; b=dk97uCC9eTZDIThzHlQHpM1VeHbvxQvgJVNFvYYDRZIQIFwMrQ/opvv/yRR5M89hjvVZPl v19y2p323GO42fKnNDfq0SNaqK8xySCzsK+hOyYBeddCW3O2xG9TH19XQvdlEm+JbM/3Or EQxswCb17sj0U3M7Z38Z/RwKxqZdNCTCu4qYjG8J9fjplrjTED9wv0IyxqlcYfJwGF+gsU DqnZFEbhJRCe0hFvh0teRoR0WUsdOIdFOLlon3zvAAx2UQkC9Apl5V+FRXRoz/ude2WO54 8M3PV2S50Z0AogMHv52HBlvByPyIK+9H6ihA1czKOyVUBWxL2n8kt/zSyd/PWQ== From: "Yufan Dou" X-Mailer: git-send-email 2.53.0 X-Original-From: Yufan Dou X-Lms-Return-Path: To: , , Cc: , , , , , , , , , , , , , , Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260806072256.1813-1-douyufan@picoheart.com> In-Reply-To: <20260806072256.1813-1-douyufan@picoheart.com> Received: from 5CG30262N9-QAP.localdomain ([58.250.122.114]) by smtp.feishu.cn with ESMTPS; Thu, 06 Aug 2026 15:22:59 +0800 Subject: [PATCH 1/3] riscv: kexec_file: constrain extra segments to the Sv39 direct map Date: Thu, 6 Aug 2026 15:22:54 +0800 Message-Id: <20260806072256.1813-2-douyufan@picoheart.com> Content-Transfer-Encoding: quoted-printable 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 59d4bbc848a8..70d84fc90178 100644 --- a/arch/riscv/kernel/machine_kexec_file.c +++ b/arch/riscv/kernel/machine_kexec_file.c @@ -254,6 +254,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, @@ -267,7 +290,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 Fri Oct 2 01:55:57 2026 Received: from va-2-41.ptr.blmpb.com (va-2-41.ptr.blmpb.com [209.127.231.41]) (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 1576F3D667D for ; Thu, 6 Aug 2026 07:23:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000998; cv=none; b=YVB5/9lstyC7SO0rhb9r9KFXgZhN/o/eRifFD6m2ctr2Sw6f8Mn4TqJUzZm7lcChK0F/Z781WcLV2JiV96ZqNwQTL4qkppJ5N+POODWIkH+GWEaEm7phVz7YyoeIaKMUu8Da4lKD6bVxkRJ+0bIPjB9nAD25UzOewnABqzeYcKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000998; c=relaxed/simple; bh=DX0h9Kv8RfaRB4Jkrya9CrXRZqkgLHqMm8No277bvSU=; h=Content-Type:In-Reply-To:Subject:Date:Message-Id:Mime-Version: From:To:Cc:References; b=piLUbpVWY+Yfx/Y0e9OlY6nJb48kD90FVBkf71hHPz7JhXuW4vssHXdRYqiQdzbfOX3UOhpIow4WcqTO+r+1iuL4yFRV1GcLPriPZtmWFw0xLWgZ7NTU00p9q0l7YAB5ZWfbf3+GY7pnWdf+W3u5liXS0KjRFYNR7+IZVmNQAGw= 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=cwrbF6UP; arc=none smtp.client-ip=209.127.231.41 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="cwrbF6UP" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1786000986; 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=cwrbF6UPZGK6JfYkJo6zfsOd5NAS1ifP5ZMtmQvhi+bpL2hs6IXNjU2DXCxCpK1Q+lK8SV 0/QbJHAjGMff9LnX/6su7ogIc0w6lJdpxuE94FAFfRNdzL9baXNdseiAcr8O8hN0yFmvet jY8ksbekfCvZdEgQVzl3LBlcO6EdQIBjOwzuSvT2QF0O8KEA5dgqVMnl6oHklsIOc+Owwn lBYqBEhXYaMETNBfyvUBEO4b8z+b8Q6WU41fC9ldb75yckjoQdMHJ1K/87uXODVfgl/8Fe Dd++YBCBb6T/nq72dF1dWP7hGyPvoYiLnUbPb/uw5eWr1AHgGbDDqhPZIeLnhg== Content-Transfer-Encoding: quoted-printable X-Lms-Return-Path: In-Reply-To: <20260806072256.1813-1-douyufan@picoheart.com> X-Mailer: git-send-email 2.53.0 Subject: [PATCH 2/3] riscv: kexec_file: size the ELF placement search by the load extent Date: Thu, 6 Aug 2026 15:22:55 +0800 Message-Id: <20260806072256.1813-3-douyufan@picoheart.com> 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 ([58.250.122.114]) by smtp.feishu.cn with ESMTPS; Thu, 06 Aug 2026 15:23:03 +0800 X-Original-From: Yufan Dou From: "Yufan Dou" To: , , Cc: , , , , , , , , , , , , , , References: <20260806072256.1813-1-douyufan@picoheart.com> 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 Fri Oct 2 01:55:57 2026 Received: from va-2-43.ptr.blmpb.com (va-2-43.ptr.blmpb.com [209.127.231.43]) (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 5D88D358D37 for ; Thu, 6 Aug 2026 07:23:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000996; cv=none; b=m7X8B4IWbrnemhpjqWuNKlYVBBM3d3rFOYEMpreP9SPCv3q+c4obJf3ivGqS3JktH7780f2sI86+YpjqrLfsa+m6G6oLIu3GHXtmmSPk2shN1q0JMZm+eYZWnZRymaL9VYAoXfYNLwlMNscsfon9TztcG454Q0gQQ1ISOAmVCBQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786000996; c=relaxed/simple; bh=pD+9laa4E7WkYT99IPB3WFVAXsL8rzxMBi3kdhtqGpQ=; h=Subject:Date:From:References:Content-Type:To:Message-Id: Mime-Version:In-Reply-To:Cc; b=Ud12zK6CV0l7DCEIBl/00KvoDoU7z+Tei6wnXL7HuoI0e2STH6TO46UJMS9h3F43pfusqqEIxRCSeJzxikjXf+KyHt314fFgVoMGwHaZQ0+09wfqWOzxFvMPqc+0dixNSz584RQL+PRh5Y1r7mH2/X+kRU7cx25I/TMMXVgGjo4= 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=BA4U4IU0; arc=none smtp.client-ip=209.127.231.43 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="BA4U4IU0" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=feishu2604151535; d=picoheart.com; t=1786000989; 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=BA4U4IU0OvwmJalcuPlWK51p1Y3EvkyWGybI5BsRGDxhN48jVXwwuvz4/gMWIFRHhGCNBk ne7yZX/t5CQon7bua4QbIQBkBrXhT/neE/s6F+5GMT2Z6zG5sz/M6O3d8mTvpbaUO8hQs6 8aHiGkkfoqUI4GXEglQt64atqoM9Dw06TcgIbUy/EGj28T52W9BFLX0VjsGLrBfv1G5KMu WoHY/V7CalgDMX6UQvQX0ZOQK7kB+WJ7n0xiiqUk5penUvZPb4pIaWyI+kHU6+lVw5jMJy e5ydmwu8JJUbCiKvhR29fu2Iz6wfG7Xr5532HqAX1+YyIYW9LKM+VlpCenNIMg== Subject: [PATCH 3/3] riscv: kexec: reserve the PMD-aligned kernel image range Date: Thu, 6 Aug 2026 15:22:56 +0800 X-Original-From: Yufan Dou Received: from 5CG30262N9-QAP.localdomain ([58.250.122.114]) by smtp.feishu.cn with ESMTPS; Thu, 06 Aug 2026 15:23:06 +0800 From: "Yufan Dou" References: <20260806072256.1813-1-douyufan@picoheart.com> To: , , Message-Id: <20260806072256.1813-4-douyufan@picoheart.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 In-Reply-To: <20260806072256.1813-1-douyufan@picoheart.com> Content-Transfer-Encoding: quoted-printable Cc: , , , , , , , , , , , , , , X-Lms-Return-Path: X-Mailer: git-send-email 2.53.0 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