linux-kernel - Re: [PATCH] arm64: arch_timer: XGene-1 has 31 bit, not 32 bit, arch timer.

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: <20221021194746.GA5830@zipoli.concurrent-rt.com>
Date:   Fri, 21 Oct 2022 15:47:46 -0400
From:   Joe Korty <joe.korty@...current-rt.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] arm64: arch_timer: XGene-1 has 31 bit, not 32 bit, arch
 timer.

Hi Marc,

On Fri, Oct 21, 2022 at 07:08:50PM +0100, Marc Zyngier wrote:
> Sorry, but you'll have to provide a bit more of an analysis here. As
> far as I can tell, you're just changing a parameter without properly
> describing what breaks and how.

There isn't much to analyse.  For ages, 0x7fffffff (31 bits) was the
declared width of 'arch timer' for all arm architures, and that worked.
Your patch series made the declared width vary according to which chipset
was in use, which is good, but that rewrite changed the above mask for
the XGene-1 from 0x7fffffff to 0xffffffff.  That change broke timers
for the XGene-1 since it seems that, in actuality, it has only a 31 bit
wide arch timer.  Thus declaring that arch timer has 32-bits is wrong.
This mismatch between the actual and declared sizes would cause arithmetic
errors in the calculation of timer deltas which more than accounts for
the hrtimer failures I am seeing when running 5.16+ on my Mustang XGene1.

Only one line need change, the rest are fluff:

-             return CLOCKSOURCE_MASK(32);
+             return CLOCKSOURCE_MASK(31);

> Also, this isn't much of a patch.

I don't know what this means.  The patch contains all that is needed for
the fix, no more.  I could add more comments as to _why_ it is 31 bits
not 32, but I don't know why.  I only know that the motherboard behaves
as if 31 bits is all that is available in the hardware.

> Please see the documentation on how to properly submit one.

AFAICS, the only submission mistake is that the 'Cc: stable@...r.kernel.org'
line is missing.

Regards,
Joe