From: sashiko-bot@kernel.org
To: "Yunhui Cui" <cuiyunhui@bytedance.com>,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
alex@ghiti.fr, dennis@kernel.org, tj@kernel.org, cl@gentwo.org,
oleg@redhat.com, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev,
bjorn@kernel.org, pulehui@huawei.com, puranjay@kernel.org,
broonie@kernel.org, dave@stgolabs.net,
david.laight.linux@gmail.com, jszhang@kernel.org,
tglx@kernel.org, conor.dooley@microchip.com, thuth@redhat.com,
ajones@ventanamicro.com, ben.dooks@codethink.co.uk,
rkrcmar@ventanamicro.com, samuel.holland@sifive.com,
zong.li@sifive.com, debug@rivosinc.com, seanwascoding@gmail.com,
andybnac@gmail.com, menglong8.dong@gmail.com,
cyrilbur@tenstorrent.com, wangruikang@iscas.ac.cn,
atishp@rivosinc.com, apatel@ventanamicro.com, arnd@arndb.de,
nathan@kernel.org, nick.desaulniers+lkml@gmail.com,
morbo@google.com, justinstitt@google.com,
qingfang.deng@siflower.com.cn, linux-mm@kvack.org,
bpf@vger.kernel.org
Subject: Re: [PATCH v10 2/9] riscv: add infrastructure for preemptible this_cpu operations
Date: Thu, 12 Nov 2026 11:05:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-210988@kernel.org> (raw)
In-Reply-To: <20261112104149.38589-3-cuiyunhui@bytedance.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] riscv: ptrace: wrong x0 offset assumption in
riscv_pcpu_regs_fixup()
- [Low] riscv: entry: non-__always_inline helpers called from noinstr
riscv_pcpu_regs_fixup()
--
commit dbc8e3fbcb707ac729e711e7321ce4a62f50767e
Author: Yunhui Cui <cuiyunhui@bytedance.com>
riscv: add infrastructure for preemptible this_cpu operations
This commit adds per-task and exception-frame tracking for registers used in
preemptible per-CPU operations so exception return can fix up the per-CPU
offset and address registers if the task migrated.
Link: https://lore.kernel.org/r/20261108213254.67805ef0@pumpkin
Link: https://lore.kernel.org/r/avG07pmpcLGkq5i-@xhacker
> diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
> index addc8188152f7..ceff8f63bc866 100644
> --- a/arch/riscv/include/asm/ptrace.h
> +++ b/arch/riscv/include/asm/ptrace.h
> @@ -53,6 +53,8 @@ struct pt_regs {
> unsigned long cause;
> /* a0 value before the syscall */
> unsigned long orig_a0;
> + /* Active preemptible per-CPU operation, if any. */
> + unsigned long pcpu_gprs;
> };
>
> #define PTRACE_SYSEMU 0x1f
> @@ -145,6 +147,19 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
> return *(unsigned long *)((unsigned long)regs + offset);
> }
>
> +static inline void regs_set_register(struct pt_regs *regs,
> + unsigned int offset, unsigned long val)
> +{
> + if (unlikely(offset > MAX_REG_OFFSET))
> + return;
> +
> + /* Register x0 is represented by the first, read-only slot. */
> + if (offset)
> + *(unsigned long *)((unsigned long)regs + offset) = val;
> +}
> +
> +void noinstr riscv_pcpu_regs_fixup(struct pt_regs *regs);
[Severity: Low]
Should regs_get_register() and regs_set_register() (or the GPR helpers called
by riscv_pcpu_regs_fixup()) be marked __always_inline?
riscv_pcpu_regs_fixup() is a noinstr function called from ret_from_exception
after irqentry_exit(), and under sanitizer configurations such as KASAN or
KCSAN the compiler may not inline plain static inline functions into a
noinstr caller.
[ ... ]
> diff --git a/arch/riscv/kernel/entry-common.c b/arch/riscv/kernel/entry-common.c
> new file mode 100644
> index 0000000000000..023d856b1679b
> --- /dev/null
> +++ b/arch/riscv/kernel/entry-common.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/bitfield.h>
> +#include <linux/compiler.h>
> +#include <linux/percpu.h>
> +
> +#include <asm/current.h>
> +#include <asm/ptrace.h>
> +
> +/*
> + * If the interrupted context had an active per-CPU operation, rewrite its
> + * saved offset and address registers for the CPU on which it will resume.
> + */
> +void noinstr riscv_pcpu_regs_fixup(struct pt_regs *regs)
> +{
> + unsigned long pcpu_offset = __my_cpu_offset;
> + unsigned long gprs = regs->pcpu_gprs;
> + unsigned long pcp;
> + unsigned int reg_pcp;
> + unsigned int reg_off;
> + unsigned int reg_addr;
> +
> + reg_pcp = FIELD_GET(PCPU_GPR_PCP, gprs);
> + reg_off = FIELD_GET(PCPU_GPR_OFF, gprs);
> + reg_addr = FIELD_GET(PCPU_GPR_ADDR, gprs);
> +
> + /* pt_regs offset zero represents x0, followed by x1 through x31. */
> + pcp = regs_get_register(regs, reg_pcp * sizeof(unsigned long));
> + regs_set_register(regs, reg_off * sizeof(unsigned long), pcpu_offset);
> + regs_set_register(regs, reg_addr * sizeof(unsigned long),
> + pcp + pcpu_offset);
> +}
[Severity: Medium]
Does riscv_pcpu_regs_fixup() read regs->epc instead of 0 if reg_pcp is x0?
Offset 0 of struct pt_regs is epc rather than x0, and regs_get_register(regs,
0) returns regs->epc without special-casing offset 0. By contrast,
regs_set_register() treats offset 0 as read-only x0, making it inconsistent
with regs_get_register() and regs_query_register_offset() for epc while
duplicating regs_get_gpr() and regs_set_gpr() in arch/riscv/mm/extable.c:
arch/riscv/mm/extable.c:regs_get_gpr() {
if (unlikely(!offset || offset > MAX_REG_OFFSET))
return 0;
return *(unsigned long *)((unsigned long)regs + offset);
}
Sharing regs_get_gpr() and regs_set_gpr() (or providing dedicated GPR-index
helpers) would return 0 for x0 and keep the byte-offset regs_get_register()
API consistent.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112104149.38589-1-cuiyunhui@bytedance.com?part=2
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Yunhui Cui" <cuiyunhui@bytedance.com>,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
alex@ghiti.fr, dennis@kernel.org, tj@kernel.org, cl@gentwo.org,
oleg@redhat.com, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev,
bjorn@kernel.org, pulehui@huawei.com, puranjay@kernel.org,
broonie@kernel.org, dave@stgolabs.net,
david.laight.linux@gmail.com, jszhang@kernel.org,
tglx@kernel.org, conor.dooley@microchip.com, thuth@redhat.com,
ajones@ventanamicro.com, ben.dooks@codethink.co.uk,
rkrcmar@ventanamicro.com, samuel.holland@sifive.com,
zong.li@sifive.com, debug@rivosinc.com, seanwascoding@gmail.com,
andybnac@gmail.com, menglong8.dong@gmail.com,
cyrilbur@tenstorrent.com, wangruikang@iscas.ac.cn,
atishp@rivosinc.com, apatel@ventanamicro.com, arnd@arndb.de,
nathan@kernel.org, nick.desaulniers+lkml@gma il.com,
morbo@google.com, justinstitt@google.com,
qingfang.deng@siflower.com.cn, linux-mm@kvack.org,
bpf@vger.kernel.org
Subject: Re: [PATCH v10 2/9] riscv: add infrastructure for preemptible this_cpu operations
Date: Thu, 12 Nov 2026 11:05:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-210988@kernel.org> (raw)
In-Reply-To: <20261112104149.38589-3-cuiyunhui@bytedance.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] riscv: ptrace: wrong x0 offset assumption in
riscv_pcpu_regs_fixup()
- [Low] riscv: entry: non-__always_inline helpers called from noinstr
riscv_pcpu_regs_fixup()
--
commit dbc8e3fbcb707ac729e711e7321ce4a62f50767e
Author: Yunhui Cui <cuiyunhui@bytedance.com>
riscv: add infrastructure for preemptible this_cpu operations
This commit adds per-task and exception-frame tracking for registers used in
preemptible per-CPU operations so exception return can fix up the per-CPU
offset and address registers if the task migrated.
Link: https://lore.kernel.org/r/20261108213254.67805ef0@pumpkin
Link: https://lore.kernel.org/r/avG07pmpcLGkq5i-@xhacker
> diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
> index addc8188152f7..ceff8f63bc866 100644
> --- a/arch/riscv/include/asm/ptrace.h
> +++ b/arch/riscv/include/asm/ptrace.h
> @@ -53,6 +53,8 @@ struct pt_regs {
> unsigned long cause;
> /* a0 value before the syscall */
> unsigned long orig_a0;
> + /* Active preemptible per-CPU operation, if any. */
> + unsigned long pcpu_gprs;
> };
>
> #define PTRACE_SYSEMU 0x1f
> @@ -145,6 +147,19 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
> return *(unsigned long *)((unsigned long)regs + offset);
> }
>
> +static inline void regs_set_register(struct pt_regs *regs,
> + unsigned int offset, unsigned long val)
> +{
> + if (unlikely(offset > MAX_REG_OFFSET))
> + return;
> +
> + /* Register x0 is represented by the first, read-only slot. */
> + if (offset)
> + *(unsigned long *)((unsigned long)regs + offset) = val;
> +}
> +
> +void noinstr riscv_pcpu_regs_fixup(struct pt_regs *regs);
[Severity: Low]
Should regs_get_register() and regs_set_register() (or the GPR helpers called
by riscv_pcpu_regs_fixup()) be marked __always_inline?
riscv_pcpu_regs_fixup() is a noinstr function called from ret_from_exception
after irqentry_exit(), and under sanitizer configurations such as KASAN or
KCSAN the compiler may not inline plain static inline functions into a
noinstr caller.
[ ... ]
> diff --git a/arch/riscv/kernel/entry-common.c b/arch/riscv/kernel/entry-common.c
> new file mode 100644
> index 0000000000000..023d856b1679b
> --- /dev/null
> +++ b/arch/riscv/kernel/entry-common.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/bitfield.h>
> +#include <linux/compiler.h>
> +#include <linux/percpu.h>
> +
> +#include <asm/current.h>
> +#include <asm/ptrace.h>
> +
> +/*
> + * If the interrupted context had an active per-CPU operation, rewrite its
> + * saved offset and address registers for the CPU on which it will resume.
> + */
> +void noinstr riscv_pcpu_regs_fixup(struct pt_regs *regs)
> +{
> + unsigned long pcpu_offset = __my_cpu_offset;
> + unsigned long gprs = regs->pcpu_gprs;
> + unsigned long pcp;
> + unsigned int reg_pcp;
> + unsigned int reg_off;
> + unsigned int reg_addr;
> +
> + reg_pcp = FIELD_GET(PCPU_GPR_PCP, gprs);
> + reg_off = FIELD_GET(PCPU_GPR_OFF, gprs);
> + reg_addr = FIELD_GET(PCPU_GPR_ADDR, gprs);
> +
> + /* pt_regs offset zero represents x0, followed by x1 through x31. */
> + pcp = regs_get_register(regs, reg_pcp * sizeof(unsigned long));
> + regs_set_register(regs, reg_off * sizeof(unsigned long), pcpu_offset);
> + regs_set_register(regs, reg_addr * sizeof(unsigned long),
> + pcp + pcpu_offset);
> +}
[Severity: Medium]
Does riscv_pcpu_regs_fixup() read regs->epc instead of 0 if reg_pcp is x0?
Offset 0 of struct pt_regs is epc rather than x0, and regs_get_register(regs,
0) returns regs->epc without special-casing offset 0. By contrast,
regs_set_register() treats offset 0 as read-only x0, making it inconsistent
with regs_get_register() and regs_query_register_offset() for epc while
duplicating regs_get_gpr() and regs_set_gpr() in arch/riscv/mm/extable.c:
arch/riscv/mm/extable.c:regs_get_gpr() {
if (unlikely(!offset || offset > MAX_REG_OFFSET))
return 0;
return *(unsigned long *)((unsigned long)regs + offset);
}
Sharing regs_get_gpr() and regs_set_gpr() (or providing dedicated GPR-index
helpers) would return 0 for x0 and keep the byte-offset regs_get_register()
API consistent.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112104149.38589-1-cuiyunhui@bytedance.com?part=2
next prev parent reply other threads:[~2026-11-12 11:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 10:41 [PATCH v10 0/9] riscv: optimize percpu access Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 1/9] riscv: store percpu offset into thread_info Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 2/9] riscv: add infrastructure for preemptible this_cpu operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 11:05 ` sashiko-bot [this message]
2026-11-12 11:05 ` sashiko-bot
2026-11-12 12:02 ` David Laight
2026-11-12 12:02 ` David Laight
2026-11-12 10:41 ` [PATCH v10 3/9] riscv: implement preemptible this_cpu read and write operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 4/9] riscv: implement preemptible this_cpu void RMW operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 5/9] riscv: implement preemptible this_cpu add_return operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 12:09 ` David Laight
2026-11-12 12:09 ` David Laight
2026-11-12 10:41 ` [PATCH v10 6/9] riscv: implement preemptible this_cpu xchg operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 7/9] riscv: implement preemptible this_cpu cmpxchg operations Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 8/9] riscv: implement preemptible this_cpu cmpxchg128 Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 10:41 ` [PATCH v10 9/9] riscv: select HAVE_CMPXCHG_LOCAL Yunhui Cui
2026-11-12 10:41 ` Yunhui Cui
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 11:30 ` bot+bpf-ci
2026-11-12 12:10 ` [PATCH v10 0/9] riscv: optimize percpu access Jisheng Zhang
2026-11-12 12:10 ` Jisheng Zhang
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-210988@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=andrii@kernel.org \
--cc=andybnac@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=atishp@rivosinc.com \
--cc=ben.dooks@codethink.co.uk \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=broonie@kernel.org \
--cc=cl@gentwo.org \
--cc=conor.dooley@microchip.com \
--cc=cuiyunhui@bytedance.com \
--cc=cyrilbur@tenstorrent.com \
--cc=daniel@iogearbox.net \
--cc=dave@stgolabs.net \
--cc=david.laight.linux@gmail.com \
--cc=debug@rivosinc.com \
--cc=dennis@kernel.org \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=jszhang@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-mm@kvack.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=menglong8.dong@gmail.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=pulehui@huawei.com \
--cc=puranjay@kernel.org \
--cc=qingfang.deng@siflower.com.cn \
--cc=rkrcmar@ventanamicro.com \
--cc=samuel.holland@sifive.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanwascoding@gmail.com \
--cc=song@kernel.org \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=tj@kernel.org \
--cc=wangruikang@iscas.ac.cn \
--cc=yonghong.song@linux.dev \
--cc=zong.li@sifive.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.