From: sashiko-bot@kernel.org
To: "Zhanpeng Zhang" <zhangzhanpeng.jasper@bytedance.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v12 02/11] riscv: add support for SBI Supervisor Software Events extension
Date: Thu, 29 Oct 2026 12:12:34 +0000 [thread overview]
Message-ID: <sashiko-outbox-189261@kernel.org> (raw)
In-Reply-To: <20261029074853.35467-3-zhangzhanpeng.jasper@bytedance.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] riscv: sbi_sse: field-spanning memcpy() on regs->a6 in do_sse()
- [High] riscv: sse: avoid clobbering tp with NULL in handle_sse() during __switch_to()
--
commit bce7a5b04f20b2889a18e324f4cb5a0c7506b960
Author: Clément Léger <cleger@rivosinc.com>
riscv: add support for SBI Supervisor Software Events extension
This commit adds architectural support for the RISC-V SBI Supervisor
Software Events (SSE) extension, including dedicated per-event stacks,
shadow call stacks, and low-level entry and exit assembly handling.
Link: https://lore.kernel.org/r/as79MHtNYd-VbUug@hu-himchau-blr.qualcomm.com/
> diff --git a/arch/riscv/kernel/sbi_sse.c b/arch/riscv/kernel/sbi_sse.c
> new file mode 100644
> index 0000000000000..032fcc07abcf7
> --- /dev/null
> +++ b/arch/riscv/kernel/sbi_sse.c
> @@ -0,0 +1,251 @@
[ ... ]
> +void noinstr do_sse(struct sse_event_arch_data *arch_evt,
> + struct pt_regs *regs, unsigned long hstatus)
> +{
> + struct riscv_sse_interrupted_context context = { regs, hstatus };
> + struct riscv_sse_interrupted_context *previous;
> + struct sbiret sret;
> +
> + nmi_enter();
> + instrumentation_begin();
> +
> + /* Retrieve missing GPRs from SBI */
> + sret = sbi_ecall(SBI_EXT_SSE, SBI_SSE_EVENT_ATTR_READ, arch_evt->evt_id,
> + SBI_SSE_ATTR_INTERRUPTED_A6,
> + (SBI_SSE_ATTR_INTERRUPTED_A7 -
> + SBI_SSE_ATTR_INTERRUPTED_A6) + 1,
> + (unsigned long)arch_evt->interrupted_phys, 0, 0);
> + if (sret.error) {
> + pr_warn("Failed to read interrupted registers for event %x: %ld\n",
> + arch_evt->evt_id, sret.error);
> + /* Let the client quiesce its source without using incomplete regs. */
> + sse_handle_event(arch_evt, NULL);
> + goto out;
> + }
> +
> + memcpy(®s->a6, arch_evt->interrupted,
> + sizeof(*arch_evt->interrupted));
> +
> + /* Make the interrupted frame visible while clients handle this event. */
> + previous = this_cpu_read(riscv_sse_interrupted_context);
> + this_cpu_write(riscv_sse_interrupted_context, &context);
> + sse_handle_event(arch_evt, regs);
> + this_cpu_write(riscv_sse_interrupted_context, previous);
> +
> + if (memcmp(®s->a6, arch_evt->interrupted,
> + sizeof(*arch_evt->interrupted))) {
> + memcpy(arch_evt->interrupted, ®s->a6,
> + sizeof(*arch_evt->interrupted));
[Severity: High]
Does passing ®s->a6 to memcpy() and memcmp() with
sizeof(*arch_evt->interrupted) trigger a field-spanning overflow under
CONFIG_FORTIFY_SOURCE=y?
In struct pt_regs (arch/riscv/include/asm/ptrace.h), a6 and a7 are separate
unsigned long members:
struct_group(a_regs,
unsigned long a0;
...
unsigned long a6;
unsigned long a7;
);
Because ®s->a6 points to a single unsigned long field while
sizeof(*arch_evt->interrupted) spans two unsigned longs (a6 and a7),
fortify_memcpy_chk() sees __builtin_object_size(®s->a6, 1) as smaller than
the copy size. This triggers a compile-time __write_overflow_field() error
when CONFIG_FORTIFY_SOURCE=y and CONFIG_WERROR=y are enabled (as well as
__read_overflow2_field() under W=1), or a runtime fortify_warn_once() inside
NMI context when an SSE event is delivered.
Could do_sse() read and write regs->a6 and regs->a7 directly (or group them
with struct_group()) instead of using memcpy() and memcmp() across the field
boundary?
[ ... ]
> diff --git a/arch/riscv/kernel/sbi_sse_entry.S b/arch/riscv/kernel/sbi_sse_entry.S
> new file mode 100644
> index 0000000000000..1e38fbb1c2a42
> --- /dev/null
> +++ b/arch/riscv/kernel/sbi_sse_entry.S
> @@ -0,0 +1,237 @@
[ ... ]
> + asm_per_cpu_with_cpu t2 __sbi_sse_entry_task t1 t3
> + REG_L tp, 0(t2)
> + bnez tp, .Lcurrent_task_found
> +
> + /* __switch_to() marks its transition window with a NULL entry task. */
> + REG_L tp, PT_TP(sp)
> +
> +.Lcurrent_task_found:
> + /* Nested exceptions temporarily replace these with the SSE stack. */
> + REG_L s6, TASK_TI_KERNEL_SP(tp)
[Severity: High]
Can a higher-priority nested SSE event observe a NULL tp here if the first
event interrupted __switch_to()?
In __switch_to() (arch/riscv/kernel/entry.S), __sbi_sse_entry_task is cleared
to zero during the task switch window, relying on the interrupted tp register
remaining valid:
asm_per_cpu t0, __sbi_sse_entry_task, t1
REG_S zero, 0(t0)
When a lower-priority SSE event arrives during this window, handle_sse saves
the valid tp into PT_TP(sp) on its stack and then executes:
REG_L tp, 0(t2)
bnez tp, .Lcurrent_task_found
REG_L tp, PT_TP(sp)
Because REG_L tp, 0(t2) loads NULL directly into tp before checking for zero,
both __sbi_sse_entry_task and the live tp register are simultaneously NULL
between those two loads. If a higher-priority SSE event preempts handle_sse
in that window, the nested handle_sse saves tp (now NULL) into its own
PT_TP(sp), loads NULL from __sbi_sse_entry_task, reloads NULL from PT_TP(sp),
and dereferences NULL at REG_L s6, TASK_TI_KERNEL_SP(tp).
Would loading __sbi_sse_entry_task into a temporary register first and only
moving it into tp when non-zero avoid clobbering the live tp register?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029074853.35467-1-zhangzhanpeng.jasper@bytedance.com?part=2
next prev parent reply other threads:[~2026-10-29 12:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 7:48 [PATCH v12 00/11] riscv: add SBI Supervisor Software Events support Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 7:48 ` [PATCH v12 01/11] riscv: add SBI SSE extension definitions Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 11:53 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 02/11] riscv: add support for SBI Supervisor Software Events extension Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 12:12 ` sashiko-bot [this message]
2026-10-29 13:48 ` Himanshu Chauhan
2026-10-29 13:48 ` Himanshu Chauhan
2026-10-29 14:46 ` Zhanpeng Zhang
2026-10-29 14:46 ` Zhanpeng Zhang
2026-10-29 7:48 ` [PATCH v12 03/11] riscv: sse: mask events during shutdown and kexec Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 11:49 ` Himanshu Chauhan
2026-10-29 11:49 ` Himanshu Chauhan
2026-10-29 12:00 ` Zhanpeng Zhang
2026-10-29 12:00 ` Zhanpeng Zhang
2026-10-29 12:10 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 04/11] drivers: firmware: add riscv SSE support Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 12:19 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 05/11] riscv: mm: avoid enabling interrupts for nofault page faults Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 12:03 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 06/11] riscv: enable NMI-safe lockdep irqflags tracking Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 11:59 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 07/11] perf: RISC-V: support callchains with SSE delivery Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 12:20 ` sashiko-bot
2026-10-29 7:48 ` [PATCH v12 08/11] perf: RISC-V: add support for SSE event Zhanpeng Zhang
2026-10-29 7:48 ` Zhanpeng Zhang
2026-10-29 12:19 ` sashiko-bot
2026-10-29 11:38 ` [PATCH v12 00/11] riscv: add SBI Supervisor Software Events support Himanshu Chauhan
2026-10-29 11:38 ` Himanshu Chauhan
2026-10-29 11:55 ` [External] " Zhanpeng Zhang
2026-10-29 11:55 ` Zhanpeng Zhang
2026-10-29 11:49 ` [PATCH v12 09/11] MAINTAINERS: add RISC-V SSE maintainers and file coverage Zhanpeng Zhang
2026-10-29 11:49 ` Zhanpeng Zhang
2026-10-29 23:09 ` Conor Dooley
2026-10-29 23:09 ` Conor Dooley
2026-10-29 11:49 ` [PATCH v12 10/11] selftests/riscv: add SSE test module Zhanpeng Zhang
2026-10-29 11:49 ` Zhanpeng Zhang
2026-10-29 12:12 ` sashiko-bot
2026-10-29 11:49 ` [PATCH v12 11/11] selftests/riscv: add perf user-stack SSE copy regression test Zhanpeng Zhang
2026-10-29 11:49 ` Zhanpeng Zhang
2026-10-29 12:05 ` sashiko-bot
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=sashiko-outbox-189261@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhangzhanpeng.jasper@bytedance.com \
/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.