Linux Trace Kernel
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>
Cc: bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	ojeda@kernel.org, gary@garyguo.net
Subject: Re: [PATCH v6 6/6] riscv: hwprobe: report whether AMO is faster than LR/SC
Date: Tue, 10 Nov 2026 14:04:25 +0000	[thread overview]
Message-ID: <sashiko-outbox-207174@kernel.org> (raw)
In-Reply-To: <20261110-lrsc-only-v6-6-bafc3cc0fcae@mobileye.com>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] riscv: hwprobe: stale vDSO cache for AMO_PERF in
  check_amo_speed_all_cpus()
- [Low] riscv: hwprobe: set_amo_speed_param() returns -EINVAL in
  __setup() handler
- [Low] riscv: hwprobe: amo_speed= override skips Zaamo check in
  check_amo_speed_all_cpus()
--

commit cbf5a1a3f9510f96205199ac1c58f59ae0d5cfb9
Author: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

riscv: hwprobe: report whether AMO is faster than LR/SC

This commit measures the relative speed of uncontended AMO instructions
versus LR/SC loops on each CPU at boot and exposes the result to userspace
via the RISCV_HWPROBE_KEY_AMO_PERF hwprobe key.

> diff --git a/arch/riscv/kernel/amo_speed.c b/arch/riscv/kernel/amo_speed.c
> new file mode 100644
> index 0000000000000..933891b69db62
> --- /dev/null
> +++ b/arch/riscv/kernel/amo_speed.c

[ ... ]

> +static int amo_speed_online_cpu(unsigned int cpu)
> +{
> +	if (per_cpu(amo_speed, cpu) != RISCV_HWPROBE_AMO_UNKNOWN)
> +		return 0;
> +
> +	if (amo_speed_param != RISCV_HWPROBE_AMO_UNKNOWN)
> +		per_cpu(amo_speed, cpu) = amo_speed_param;
> +	else
> +		check_amo_speed(NULL);
> +
> +	return 0;
> +}
> +
> +static int __init set_amo_speed_param(char *str)
> +{
> +	if (!strcmp(str, "slow"))
> +		amo_speed_param = RISCV_HWPROBE_AMO_SLOW;
> +	else if (!strcmp(str, "fast"))
> +		amo_speed_param = RISCV_HWPROBE_AMO_FAST;
> +	else
> +		return -EINVAL;
> +
> +	return 1;
> +}
> +__setup("amo_speed=", set_amo_speed_param);

[Severity: Low]
Does returning -EINVAL from a __setup() callback cause invalid amo_speed=
values to be treated as handled?  obsolete_checksetup() treats any
non-zero return value from setup_func() as success, so an unrecognized
argument is silently accepted instead of being reported as an unknown
boot option.  __setup() handlers return 0 on failure.

> +static int __init check_amo_speed_all_cpus(void)
> +{
> +	int cpu;
> +
> +	if (amo_speed_param != RISCV_HWPROBE_AMO_UNKNOWN) {
> +		pr_info("AMO speed set to '%s' (%lu) by command line\n",
> +			amo_speed_param == RISCV_HWPROBE_AMO_FAST ? "fast" : "slow",
> +			amo_speed_param);
> +		for_each_online_cpu(cpu)
> +			per_cpu(amo_speed, cpu) = amo_speed_param;

[Severity: Low]
Does the amo_speed= command-line override bypass the Zaamo extension check
in check_amo_speed_all_cpus() and amo_speed_online_cpu()?  If amo_speed=
is passed on a CPU without RISCV_ISA_EXT_ZAAMO, per_cpu(amo_speed, cpu) is
set to RISCV_HWPROBE_AMO_FAST or RISCV_HWPROBE_AMO_SLOW instead of
RISCV_HWPROBE_AMO_UNSUPPORTED, reporting to userspace that AMO
instructions are usable on hardware where they trap as illegal
instructions.

> +	} else {
> +		on_each_cpu(check_amo_speed, NULL, 1);
> +	}
> +
> +	cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "riscv:amo_speed",
> +				  amo_speed_online_cpu, NULL);
> +
> +	return 0;
> +}
> +
> +/*
> + * Same level as the unaligned access probe: after clocksource_done_booting()
> + * so that amo_speed_measure() uses a stable clocksource, but before
> + * rootfs_initcall() enables usermode helpers that can reach hwprobe.
> + */
> +fs_initcall_sync(check_amo_speed_all_cpus);

[Severity: High]
Does running check_amo_speed_all_cpus() at fs_initcall_sync leave the vDSO
hwprobe table with a stale RISCV_HWPROBE_AMO_UNKNOWN value for
RISCV_HWPROBE_KEY_AMO_PERF?

init_hwprobe_vdso_data() populates avd->all_cpu_hwprobe_values[] earlier
at arch_initcall_sync:

arch/riscv/kernel/sys_hwprobe.c:init_hwprobe_vdso_data() {
    ...
	for (key = 0; key <= RISCV_HWPROBE_MAX_KEY; key++) {
		pair.key = key;
		hwprobe_one_pair(&pair, cpu_online_mask);

		WARN_ON_ONCE(pair.key < 0);

		avd->all_cpu_hwprobe_values[key] = pair.value;
    ...
}

Because per_cpu(amo_speed, cpu) is still RISCV_HWPROBE_AMO_UNKNOWN when
init_hwprobe_vdso_data() runs, and check_amo_speed_all_cpus() does not
update vdso_k_arch_data->all_cpu_hwprobe_values[RISCV_HWPROBE_KEY_AMO_PERF]
after probing, userspace queries routed through __vdso_riscv_hwprobe()
always receive RISCV_HWPROBE_AMO_UNKNOWN.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-lrsc-only-v6-0-bafc3cc0fcae@mobileye.com?part=6

      reply	other threads:[~2026-11-10 14:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 13:20 [PATCH v6 0/6] riscv: restrict the ISA used for atomics to avoid unsupported or slow AMO Vladimir Kondratiev
2026-11-10 13:20 ` [PATCH v6 1/6] riscv: probes: reject probes inside an LR/SC sequence Vladimir Kondratiev
2026-11-10 13:20 ` [PATCH v6 2/6] riscv: build kernel atomics from LR/SC when Zaamo is disabled Vladimir Kondratiev
2026-11-10 19:02   ` Conor Dooley
2026-11-11  4:18     ` Jisheng Zhang
2026-11-11  6:37     ` Vladimir Kondratiev
2026-11-10 13:21 ` [PATCH v6 3/6] riscv: accept the atomic extensions this kernel was built with Vladimir Kondratiev
2026-11-10 13:51   ` sashiko-bot
2026-11-10 13:21 ` [PATCH v6 4/6] riscv: report the A extension when Zaamo and Zalrsc are both present Vladimir Kondratiev
2026-11-10 13:21 ` [PATCH v6 5/6] riscv, bpf: emit LR/SC loops when Zaamo is disabled Vladimir Kondratiev
2026-11-10 14:00   ` sashiko-bot
2026-11-10 13:21 ` [PATCH v6 6/6] riscv: hwprobe: report whether AMO is faster than LR/SC Vladimir Kondratiev
2026-11-10 14:04   ` 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=sashiko-outbox-207174@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=gary@garyguo.net \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vladimir.kondratiev@mobileye.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox