Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yixun Lan <dlan@gentoo.org>
To: wangjingwei@iscas.ac.cn
Cc: linux-riscv@lists.infradead.org,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Charlie Jenkins" <charlie@rivosinc.com>,
	"Tsukasa OI" <research_trasio@irq.a4lg.com>
Subject: Re: [PATCH] riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot
Date: Wed, 21 May 2025 07:52:35 +0000	[thread overview]
Message-ID: <20250521075235-GYA30582@gentoo> (raw)
In-Reply-To: <20250521052754.185231-1-wangjingwei@iscas.ac.cn>

Hi Jingwei,

On 13:27 Wed 21 May     , wangjingwei@iscas.ac.cn wrote:
> From: Jingwei Wang <wangjingwei@iscas.ac.cn>
> 
> The riscv_hwprobe vDSO data is populated by init_hwprobe_vdso_data(),
> an arch_initcall_sync. However, underlying data for some keys, like
> RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF, is determined asynchronously.
> 
> Specifically, the per_cpu(vector_misaligned_access, cpu) values are set
> by the vec_check_unaligned_access_speed_all_cpus kthread. This kthread
> is spawned by an earlier arch_initcall (check_unaligned_access_all_cpus)
> and may complete its benchmark *after* init_hwprobe_vdso_data() has
> already populated the vDSO with default/stale values.
> 
> This patch introduces riscv_hwprobe_vdso_sync(sync_key). This function
> is now called by the vec_check_unaligned_access_speed_all_cpus kthread
> upon its completion. It re-evaluates the specified key using current kernel
> state (including the finalized per-CPU data) via hwprobe_one_pair()
> and updates the corresponding entry in vdso_k_arch_data.
> 
Personally, it's unnecessary to explain the patch line by line, 
giving a high level summary would be great

> This ensures the vDSO accurately reflects the final boot-time values
> for keys determined by such asynchronous boot tasks, resolving observed
> inconsistencies when userspace starts.
> 
> Test by comparing vDSO and syscall results for affected keys
> (e.g., MISALIGNED_VECTOR_PERF), which now match their final
> boot-time values.
> 
> Reported-by: Tsukasa OI <research_trasio@irq.a4lg.com>
> Closes: https://lore.kernel.org/linux-riscv/760d637b-b13b-4518-b6bf-883d55d44e7f@irq.a4lg.com/
As you give a Closes tag here, so I'd ask

Can you check which commit introduced this problem? it might warrant
a Fixes tag, please also CC stable if needed

(Check the kernel commit log for what's format of Fixes tag,
 12 charactors for hash + full commit title)

> Signed-off-by: Jingwei Wang <wangjingwei@iscas.ac.cn>
> ---
>  arch/riscv/include/asm/hwprobe.h           |  4 ++++
>  arch/riscv/kernel/sys_hwprobe.c            | 16 ++++++++++++++++
>  arch/riscv/kernel/unaligned_access_speed.c |  4 +++-
>  3 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
> index 1f690fea0e03de6a..02c34f03d8b9bc83 100644
> --- a/arch/riscv/include/asm/hwprobe.h
> +++ b/arch/riscv/include/asm/hwprobe.h
> @@ -40,4 +40,8 @@ static inline bool riscv_hwprobe_pair_cmp(struct riscv_hwprobe *pair,
>  	return pair->value == other_pair->value;
>  }
>  
> +#ifdef CONFIG_MMU
> +void riscv_hwprobe_vdso_sync(s64 sync_key);
> +#endif /* CONFIG_MMU */
> +
we usually try to avoid repeat "#ifdef CONFIG_MMU" in header & c file (unaligned_access_speed.c)
so, you can do

#ifdef CONFIG_MMU
void riscv_hwprobe_vdso_sync(s64 sync_key);
#else
static inline void riscv_hwprobe_vdso_sync(s64 sync_key) { };
#endif /* CONFIG_MMU */


>  #endif
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index 249aec8594a92a80..c2593bd766055d35 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -17,6 +17,7 @@
>  #include <asm/vector.h>
>  #include <asm/vendor_extensions/thead_hwprobe.h>
>  #include <vdso/vsyscall.h>
> +#include <vdso/datapage.h>
>  
>  
>  static void hwprobe_arch_id(struct riscv_hwprobe *pair,
> @@ -500,6 +501,21 @@ static int __init init_hwprobe_vdso_data(void)
>  
>  arch_initcall_sync(init_hwprobe_vdso_data);
>  
> +void riscv_hwprobe_vdso_sync(s64 sync_key)
> +{
> +	struct vdso_arch_data *avd = vdso_k_arch_data;
> +	struct riscv_hwprobe pair;
> +
> +	pair.key = sync_key;
> +	hwprobe_one_pair(&pair, cpu_online_mask);
> +	/*
> +	 * Update vDSO data for the given key.
> +	 * Currently for non-ID key updates (e.g. MISALIGNED_VECTOR_PERF),
> +	 * so 'homogeneous_cpus' is not re-evaluated here.
> +	 */
> +	avd->all_cpu_hwprobe_values[sync_key] = pair.value;
> +}
> +
>  #endif /* CONFIG_MMU */
>  
>  SYSCALL_DEFINE5(riscv_hwprobe, struct riscv_hwprobe __user *, pairs,
> diff --git a/arch/riscv/kernel/unaligned_access_speed.c b/arch/riscv/kernel/unaligned_access_speed.c
> index 585d2dcf2dab1ccb..7194aee3bf3234e5 100644
> --- a/arch/riscv/kernel/unaligned_access_speed.c
> +++ b/arch/riscv/kernel/unaligned_access_speed.c
> @@ -375,7 +375,9 @@ static void check_vector_unaligned_access(struct work_struct *work __always_unus
>  static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
>  {
>  	schedule_on_each_cpu(check_vector_unaligned_access);
> -
> +#ifdef CONFIG_MMU
> +	riscv_hwprobe_vdso_sync(RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF);
> +#endif
>  	return 0;
>  }
>  #else /* CONFIG_RISCV_PROBE_VECTOR_UNALIGNED_ACCESS */
> -- 
> 2.49.0
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-05-21  7:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  5:27 [PATCH] riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot wangjingwei
2025-05-21  7:52 ` Yixun Lan [this message]
2025-05-22  1:40   ` 王经纬

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=20250521075235-GYA30582@gentoo \
    --to=dlan@gentoo.org \
    --cc=ajones@ventanamicro.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=charlie@rivosinc.com \
    --cc=cleger@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=research_trasio@irq.a4lg.com \
    --cc=wangjingwei@iscas.ac.cn \
    /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