mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Walmsley <pjw@kernel.org>
To: Nam Cao <namcao@linutronix.de>
Cc: Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	 Andrew Jones <andrew.jones@oss.qualcomm.com>,
	 Jingwei Wang <wangjingwei@iscas.ac.cn>,
	 Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>,
	 linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH 1/2] riscv: unaligned: stop using kthread for check_vector_unaligned_access()
Date: Wed, 29 Jul 2026 13:31:48 -0600 (MDT)	[thread overview]
Message-ID: <dd5ff254-fc7c-ddd2-751a-50e6971b10af@kernel.org> (raw)
In-Reply-To: <1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de>

Hi,

On Wed, 17 Jun 2026, Nam Cao wrote:

> A kthread is used to run check_vector_unaligned_access() to optimize boot
> time, allowing the kernel to continue booting without waiting for the
> unaligned vector speed probe to finish.
> 
> However, this asynchronous approach introduces several complications.
> First, the kthread may not complete before a user reads vDSO data,
> resulting in incorrect values. This was previously addressed by
> commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for
> late-initialized keys at boot"), which added complex synchronization
> between the kthread and vDSO reads.
> 
> Second, it was discovered that the kthread may not finish before
> vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed,
> triggering a page fault.
> 
> These issues raise the question of whether the kthread is worth the added
> complexity. A past boot time regression report was actually unrelated to
> synchronous probing; it was caused by the probe running serially. Since
> switching to a parallel probe, no further complaints have been made.
> Furthermore, the unaligned scalar access speed probe takes the same amount
> of time, runs synchronously, and has caused no issues.
> 
> Testing shows no noticeable boot time slowdown when running the vector
> probe synchronously (0.464474s with kthread vs. 0.457991s without).
> 
> Remove the kthread usage and run the probe synchronously. This simplifies
> the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv:
> hwprobe: Fix stale vDSO data for late-initialized keys at boot")
>
> Reported-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
> Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/
> Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Nam Cao <namcao@linutronix.de>

Thanks, will queue this for v7.3, but I think the Fixes: tag should point 
to e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe"), 
since the problems that you mention are due to the use of kthreads.  
So I'll plan to update this accordingly when it's queued.


- Paul

  parent reply	other threads:[~2026-07-29 19:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17  3:38 [PATCH 0/2] riscv: unaligned: stop using kthread for vector speed probe Nam Cao
2026-06-17  3:38 ` [PATCH 1/2] riscv: unaligned: stop using kthread for check_vector_unaligned_access() Nam Cao
2026-06-17  8:49   ` Nam Cao
2026-06-29 20:52   ` Jesse Taube
2026-07-29 19:31   ` Paul Walmsley [this message]
2026-06-17  3:38 ` [PATCH 2/2] Revert "riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot" Nam Cao
2026-07-29 19:32   ` Paul Walmsley
2026-06-17 14:21 ` [PATCH 0/2] riscv: unaligned: stop using kthread for vector speed probe Anirudh Srinivasan

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=dd5ff254-fc7c-ddd2-751a-50e6971b10af@kernel.org \
    --to=pjw@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=andrew.jones@oss.qualcomm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=asrinivasan@oss.tenstorrent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=namcao@linutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=stable@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®