All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, arnd@arndb.de,
	kernel-team@meta.com, vincenzo.frascino@arm.com,
	anders.roxell@linaro.org
Subject: Re: [PATCH RFC] arm64: vdso: Use __arch_counter_get_cntvct()
Date: Wed, 02 Apr 2025 23:04:41 +0100	[thread overview]
Message-ID: <87a58yz0cm.wl-maz@kernel.org> (raw)
In-Reply-To: <20250402-arm-vdso-v1-1-2e7a12d75107@debian.org>

On Wed, 02 Apr 2025 20:22:47 +0100,
Breno Leitao <leitao@debian.org> wrote:
> 
> While reading how `cntvct_el0` was read in the kernel, I found that
> __arch_get_hw_counter() is doing something very similar to what
> __arch_counter_get_cntvct() is already doing.
> 
> Use the existing __arch_counter_get_cntvct() function instead of
> duplicating similar inline assembly code in __arch_get_hw_counter().
> 
> Both functions were performing nearly identical operations to read the
> cntvct_el0 register. The only difference was that
> __arch_get_hw_counter() included a memory clobber in its inline
> assembly, which appears unnecessary in this context.
> 
> This change simplifies the code by eliminating duplicate functionality
> and improves maintainability by centralizing the counter access logic in
> a single implementation.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> I'm sharing this code as an RFC since I'm not intimately familiar with
> different arm platforms, and I want to double-check that I haven't
> missed anything subtle.
> ---
>  arch/arm64/include/asm/vdso/gettimeofday.h | 22 ++--------------------
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h b/arch/arm64/include/asm/vdso/gettimeofday.h
> index 92a2b59a9f3df..417b5b41b877d 100644
> --- a/arch/arm64/include/asm/vdso/gettimeofday.h
> +++ b/arch/arm64/include/asm/vdso/gettimeofday.h
> @@ -11,6 +11,7 @@
>  #include <asm/barrier.h>
>  #include <asm/unistd.h>
>  #include <asm/sysreg.h>
> +#include <asm/arch_timer.h>
>  
>  #define VDSO_HAS_CLOCK_GETRES		1
>  
> @@ -69,8 +70,6 @@ int clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
>  static __always_inline u64 __arch_get_hw_counter(s32 clock_mode,
>  						 const struct vdso_time_data *vd)
>  {
> -	u64 res;
> -
>  	/*
>  	 * Core checks for mode already, so this raced against a concurrent
>  	 * update. Return something. Core will do another round and then
> @@ -79,24 +78,7 @@ static __always_inline u64 __arch_get_hw_counter(s32 clock_mode,
>  	if (clock_mode == VDSO_CLOCKMODE_NONE)
>  		return 0;
>  
> -	/*
> -	 * If FEAT_ECV is available, use the self-synchronizing counter.
> -	 * Otherwise the isb is required to prevent that the counter value
> -	 * is speculated.
> -	*/
> -	asm volatile(
> -	ALTERNATIVE("isb\n"
> -		    "mrs %0, cntvct_el0",
> -		    "nop\n"
> -		    __mrs_s("%0", SYS_CNTVCTSS_EL0),
> -		    ARM64_HAS_ECV)
> -	: "=r" (res)
> -	:
> -	: "memory");
> -
> -	arch_counter_enforce_ordering(res);
> -
> -	return res;
> +	return __arch_counter_get_cntvct();

I won't pretend I understand it all, but you really want to have a
look at the link just above the arch_counter_enforce_ordering()
definition, pasted below for your convenience:

https://lore.kernel.org/r/alpine.DEB.2.21.1902081950260.1662@nanos.tec.linutronix.de/

Dropping this ordering enforcement seems pretty adventurous unless you
have very strong guarantees about the context this executes in.

	M.

-- 
Jazz isn't dead. It just smells funny.


  reply	other threads:[~2025-04-02 22:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 19:22 [PATCH RFC] arm64: vdso: Use __arch_counter_get_cntvct() Breno Leitao
2025-04-02 22:04 ` Marc Zyngier [this message]
2025-04-02 22:22   ` Marc Zyngier
2025-04-03 12:14     ` Breno Leitao
2025-04-03 17:59       ` Marc Zyngier
2025-04-04 13:36         ` Breno Leitao

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=87a58yz0cm.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anders.roxell@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /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.