From: sashiko-bot@kernel.org
To: fangyu.yu@linux.alibaba.com
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 9/9] riscv: kexec: Route normal kexec through the trampoline page table
Date: Thu, 04 Jun 2026 13:36:57 +0000 [thread overview]
Message-ID: <20260604133658.0AFD61F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260604132418.15725-10-fangyu.yu@linux.alibaba.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch removes the `set_memory_x()` call in `machine_kexec_prepare()` but fails to remove the corresponding `set_memory_nx()` call in `machine_kexec_cleanup()`, leading to an unbalanced page protection modification.
--
commit 1f36a552a8c04150c5598c4bdd508c89d475252b
Author: Fangyu Yu <fangyu.yu@linux.alibaba.com>
riscv: kexec: Route normal kexec through the trampoline page table
This commit routes normal kexec through a trampoline wrapper, which drops
SATP with PC already on a PA. As a result, the relocation code now runs
entirely with the MMU off.
> diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
> index 71688c63af65f..82fcb84a03ec5 100644
> --- a/arch/riscv/kernel/machine_kexec.c
> +++ b/arch/riscv/kernel/machine_kexec.c
> @@ -164,9 +164,6 @@ machine_kexec_prepare(struct kimage *image)
> memcpy(control_code_buffer, riscv_kexec_relocate,
> riscv_kexec_relocate_size);
>
> - /* Mark the control page executable */
> - set_memory_x((unsigned long) control_code_buffer, 1);
> -
[Severity: Medium]
By removing this set_memory_x() call here, does machine_kexec_cleanup()
now have an unbalanced set_memory_nx() call?
Looking at machine_kexec_cleanup() in arch/riscv/kernel/machine_kexec.c:
void
machine_kexec_cleanup(struct kimage *image)
{
...
control_code_buffer = page_address(image->control_code_page);
set_memory_nx((unsigned long)control_code_buffer, 1);
}
Since __set_memory() unconditionally splits the linear mapping on RISC-V,
will leaving this set_memory_nx() call permanently shatter direct map huge
pages down to 4KB PTEs every time a non-crash kexec image is unloaded or
fails to load?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260604132418.15725-1-fangyu.yu@linux.alibaba.com?part=9
prev parent reply other threads:[~2026-06-04 13:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 13:24 [PATCH v3 0/9] riscv: kexec: Make kexec/kdump robust under VS-mode fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 1/9] riscv: kexec: Reset executable bit on the control code page in cleanup fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 2/9] riscv: kexec: Bound FDT search by source buffer size, not destination fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:37 ` sashiko-bot
2026-06-04 13:24 ` [PATCH v3 3/9] riscv: Add kexec trampoline text section to vmlinux.lds.S fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 4/9] riscv: kexec: Place norelocate trampoline into .kexec.tramp.text fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 5/9] riscv: kexec: Build trampoline page tables for crash kernel entry fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 6/9] riscv: kexec: Switch to trampoline page table before norelocate fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:40 ` sashiko-bot
2026-06-04 13:24 ` [PATCH v3 7/9] riscv: kexec: Always build the trampoline page table fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` [PATCH v3 8/9] riscv: kexec: Add the relocate-trampoline wrapper fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:46 ` sashiko-bot
2026-06-04 13:24 ` [PATCH v3 9/9] riscv: kexec: Route normal kexec through the trampoline page table fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:24 ` fangyu.yu
2026-06-04 13:36 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260604133658.0AFD61F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fangyu.yu@linux.alibaba.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.