From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B754138A73B for ; Thu, 6 Aug 2026 18:50:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786042213; cv=none; b=NNmyJA5U8CoBGsxKHEFI8ymer1Wbwniui5nHd22lKSuJNGAMfmjl5CN1YjBBJwLcUNVo1OGKNv4KRf7h/R7VxN1u4uDl7FEA3BwwhRUrdLZlnXBYPYMBmDW1N4wIwPdqV2b6HxhCIYarxWJO3Ybjrl7izbMU+6vxoFbEzhcMx10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786042213; c=relaxed/simple; bh=Q7ETfoOvX7yrBrJvCpgwydW7hU0jk38KMTgmuChCDS0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=DsmZt72tar6Sb/aFjsgnu5OEIMVAerq4kjbPGpaD840/sx4pDKWs/lTdVFwCGyd2Fr/n0BvTlCM5ElQAlD/m7Myrl34SsZ69pbIKPywuok+EdngiVh4+DtFJUWWCdOJeiwn4h7f4kTI1B6NNEpkh5+KZFocwcXt6GFD/USMXRbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TrAnScLw; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TrAnScLw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D9081F000E9; Thu, 6 Aug 2026 18:50:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786042212; bh=RJJW14A/nX6VrjipjthjIHHraIYxFJQivG437GtHCGs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TrAnScLwiSiregMmTEqnckhD7zWRhYsvskLI1UDtohWU2LlWDN9A2GS7WPXvp3Ea2 6HYloAK24/c7IngZoukOfW0xotteDRNh5eVURCLWUiGaH8ro/Ga1OuQhrDLgAcbmmN Y5WrFB54xOr2kqC/f3BvD9P/3WFIazIjsPQuadXGy8NphCqgus6sNCAyZdFWS2DIhZ FSkV4CCYNxBpa/Dyn0LZFgQCW431JG+1UfwcB099P2qPka5KivQAUuzgpapt2uvvQY dGq9xt9bbA9suJ7/dOfZdjceVm11b6KAgd51eeae/fdnzyZHgV4JDT6S7VAv+7ZwQ2 R5fbARGkfcE1Q== Date: Thu, 6 Aug 2026 12:50:11 -0600 (MDT) From: Paul Walmsley To: Rui Qi cc: linux-riscv@lists.infradead.org, Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Nam Cao , Kees Cook , Jingwei Wang , open list Subject: Re: [PATCH] riscv: hwprobe: Register unaligned probes before usermode In-Reply-To: <20260721150511.1607105-1-qirui.001@bytedance.com> Message-ID: <8884ef1b-9fd2-7300-d7f1-38d061cabf0c@kernel.org> References: <20260721150511.1607105-1-qirui.001@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi, On Tue, 21 Jul 2026, Rui Qi wrote: > The hwprobe vDSO data is populated by the first riscv_hwprobe syscall. > Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async > vector unaligned access speed probe registered by > check_unaligned_access_all_cpus(). > > That initcall currently runs at late_initcall level. However, > rootfs_initcall enables usermode helpers before late initcalls run, so an > early helper can execute userspace and call riscv_hwprobe first. > > In that case complete_hwprobe_vdso_data() consumes the initial > pending_boot_probes reference, populates the vDSO cache, and marks it > ready before the later async probe is registered. The eventual probe > result then cannot update the already-ready cache. > > Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still > runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns() > benchmark uses a stable clocksource, but it runs before rootfs_initcall > enables usermode helpers. > > Any async hwprobe probe is therefore registered before userspace can > trigger the one-time vDSO cache population. > > Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe") > Signed-off-by: Rui Qi Now that we've queued a patch to get rid of the async hwprobe infrastructure, is this patch still needed? - Paul