lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wnatra83.wl-maz@kernel.org>
Date:   Sat, 27 Aug 2022 16:13:00 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Puyou Lu <puyou.lu@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Robert Richter <rrichter@...ium.com>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: do runtime cpu cap check only when necessary

On Sat, 27 Aug 2022 06:19:27 +0100,
Puyou Lu <puyou.lu@...il.com> wrote:
> 
> Now cpu cap check is done every exception happens on every arm64 platform,
> but this check is necessary on just few of then, so we can drop this
> check at compile time on others. This can decrease exception handle time
> on most cases.
> 
> Fixes: 6d4e11c5e2e8 ("irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154")
> Signed-off-by: Puyou Lu <puyou.lu@...il.com>
> ---
>  drivers/irqchip/irq-gic-v3.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 262658fd5f9e..3f08c2ef1251 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -237,9 +237,11 @@ static void gic_redist_wait_for_rwp(void)
>  
>  static u64 __maybe_unused gic_read_iar(void)
>  {
> +#ifdef CONFIG_CAVIUM_ERRATUM_23154
>  	if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_23154))
>  		return gic_read_iar_cavium_thunderx();
>  	else
> +#endif
>  		return gic_read_iar_common();
>  }
>  #endif

You realise that cpus_have_const_cap() results purely in a couple of
branches once the caps have been finalised, right?

Please provide data showing that it actually "can decrease exception
handle time on most cases", because I'm pretty sure you cannot measure
the difference in any meaningful way.

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ