From: sashiko-bot@kernel.org
To: "Yunhui Cui" <cuiyunhui@bytedance.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v6 2/3] riscv: introduce percpu.h into include/asm
Date: Wed, 01 Jul 2026 12:46:30 +0000 [thread overview]
Message-ID: <20260701124631.32E671F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701122948.57584-3-cuiyunhui@bytedance.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Inconsistent naming and semantics for 8/16-bit vs 32/64-bit 'andnot' percpu operations.
--
commit 8c96e5a266e5953bcbbc15476c253fbdd307508b
Author: Yunhui Cui <cuiyunhui@bytedance.com>
riscv: introduce percpu.h into include/asm
Add RISC-V specific this_cpu helpers so common percpu operations can use
short architecture sequences instead of the generic implementation.
Native-width operations use AMOs, while 8/16-bit operations use Zabha when
available and a local 32-bit LR/SC fallback otherwise.
> diff --git a/arch/riscv/include/asm/percpu.h b/arch/riscv/include/asm/percpu.h
> new file mode 100644
> index 0000000000000..34483253e946f
> --- /dev/null
> +++ b/arch/riscv/include/asm/percpu.h
[ ... ]
> +#ifdef CONFIG_64BIT
> +#define PERCPU_OP(name, amo_insn) \
> + __PERCPU_AMO_OP_CASE(.w, name, 32, amo_insn) \
> + __PERCPU_AMO_OP_CASE(.d, name, 64, amo_insn)
> +#else
> +#define PERCPU_OP(name, amo_insn) \
> + __PERCPU_AMO_OP_CASE(.w, name, 32, amo_insn)
> +#endif
> +
> +PERCPU_OP(add, add)
> +PERCPU_OP(andnot, and)
[Severity: Low]
This isn't a bug, but is the naming here intentional? This defines
__percpu_andnot_amo_case_32 and __percpu_andnot_amo_case_64, but since it
passes the 'and' instruction and operates on the value directly, it performs
a standard bitwise and rather than an and-not.
> +PERCPU_OP(or, or)
[ ... ]
> +#define PERCPU_OP_8_16(op_name, op, expr, final_op) \
> + PERCPU_8_16_OP(op_name, op, 8, .b, u8, expr, final_op); \
> + PERCPU_8_16_OP(op_name, op, 16, .h, u16, expr, final_op)
> +
> +PERCPU_OP_8_16(add, add, val, add)
> +PERCPU_OP_8_16(andnot, and, ~(val), and)
[Severity: Low]
Conversely, for 8-bit and 16-bit operations, the andnot operation actually
performs an and-not by passing ~(val).
> +PERCPU_OP_8_16(or, or, val, or)
[ ... ]
> +#define this_cpu_and_1(pcp, val) _pcp_protect(__percpu_andnot_amo_case_8, pcp, ~(val))
> +#define this_cpu_and_2(pcp, val) _pcp_protect(__percpu_andnot_amo_case_16, pcp, ~(val))
> +#define this_cpu_and_4(pcp, val) _pcp_protect(__percpu_andnot_amo_case_32, pcp, val)
> +
> +#ifdef CONFIG_64BIT
> +#define this_cpu_and_8(pcp, val) _pcp_protect(__percpu_andnot_amo_case_64, pcp, val)
> +#endif
[Severity: Low]
Because of the semantic difference between the underlying helpers, the 1 and 2
byte wrappers pass ~(val) while the 4 and 8 byte wrappers pass val.
Would it be clearer to harmonize the semantics across all sizes so the
wrappers do not have to compensate?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122948.57584-1-cuiyunhui@bytedance.com?part=2
next prev parent reply other threads:[~2026-07-01 12:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 12:29 [PATCH v6 0/3] riscv: fix PIO helpers and add optimized percpu ops Yunhui Cui
2026-07-01 12:29 ` Yunhui Cui
2026-07-01 12:29 ` [PATCH v6 1/3] riscv: io: avoid null-pointer arithmetic in PIO helpers Yunhui Cui
2026-07-01 12:29 ` Yunhui Cui
2026-07-01 12:40 ` sashiko-bot
2026-07-01 12:29 ` [PATCH v6 2/3] riscv: introduce percpu.h into include/asm Yunhui Cui
2026-07-01 12:29 ` Yunhui Cui
2026-07-01 12:46 ` sashiko-bot [this message]
2026-07-01 13:46 ` [External] " yunhui cui
2026-07-01 13:12 ` bot+bpf-ci
2026-07-01 13:12 ` bot+bpf-ci
2026-07-01 13:12 ` bot+bpf-ci
2026-07-01 12:29 ` [PATCH v6 3/3] riscv: store percpu offset into thread_info Yunhui Cui
2026-07-01 12:29 ` Yunhui Cui
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=20260701124631.32E671F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cuiyunhui@bytedance.com \
--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.