linux-kernel - Re: [PATCH] irqchip/gic-v3: move reading of GICR

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87msx8nb24.wl-maz@kernel.org>
Date:   Tue, 26 Sep 2023 17:39:31 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Rex Nie <rex.nie@...uarmicro.com>
Cc:     tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: move reading of GICR_TYPER later

On Mon, 25 Sep 2023 03:34:08 +0100,
Rex Nie <rex.nie@...uarmicro.com> wrote:
> 
> This changeset will reduce one reading of GICR_TYPER register
> when any of next 2 condictions meets:
> 1. found redistributor for current cpu
> 2. single_redist is true for gic_data.redist_regions[i]
> 
> Signed-off-by: Rex Nie <rex.nie@...uarmicro.com>
> ---
>  drivers/irqchip/irq-gic-v3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index eedfa8e9f077..d08a4773f631 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -982,7 +982,6 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  		}
>  
>  		do {
> -			typer = gic_read_typer(ptr + GICR_TYPER);
>  			ret = fn(gic_data.redist_regions + i, ptr);
>  			if (!ret)
>  				return 0;
> @@ -990,6 +989,7 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  			if (gic_data.redist_regions[i].single_redist)
>  				break;
>  
> +			typer = gic_read_typer(ptr + GICR_TYPER);
>  			if (gic_data.redist_stride) {
>  				ptr += gic_data.redist_stride;
>  			} else {

I personally prefer establishing the exit condition for the loop as
early as possible. Doing it later makes this code slightly more
fragile, and I somehow doubt that you will notice the extra reads.

Can you at least quantify the improvement?

	M.

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