linux-kernel - Re: [PATCH] drivers/clocksource/arm_arch_timer: Tighten Allwinner arch timer workaround

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]

Date:   Thu, 10 Nov 2022 08:31:21 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Ilya Dikariev <dikarill@...u.de>
Cc:     Mark Rutland <mark.rutland@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Samuel Holland <samuel@...lland.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        linux-sunxi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/clocksource/arm_arch_timer: Tighten Allwinner arch timer workaround

On Wed, 09 Nov 2022 21:10:49 +0000,
Ilya Dikariev <dikarill@...u.de> wrote:
> 
> As we know, the Allwinner A64 SoC has a buggy RCU time unit. The

What is RCU?

> workaround named UNKNOWN1 was not sufficient to cover some more buggy
> bunches of this SoC. This workaround diminish the mask to 8 bits instead
> of 9.
> 
> An example run of timer test tool https://github.com/smaeul/timer-tools
> on PinePhone device (owns the A64 SoC) gives following result on a non
> patched kernel (cut off):
> 
> Running parallel counter test...
> 0: Failed after 5507 reads (0.003578 s)
> 0: 0x0000000c8272cbf1 -> 0x0000000c8272ccff -> 0x0000000c8272cc0e (     0.011 ms)
> 2: Failed after 14518 reads (0.009248 s)
> 2: 0x0000000c827513f1 -> 0x0000000c82751300 -> 0x0000000c8275140e (    -0.010 ms)
> 3: Failed after 14112 reads (0.008730 s)
> 3: 0x0000000c8274f3f2 -> 0x0000000c8274f300 -> 0x0000000c8274f40d (    -0.010 ms)
> 1: Failed after 12030 reads (0.008409 s)
> 1: 0x0000000c8274abf1 -> 0x0000000c8274acff -> 0x0000000c8274ac0f (     0.011 ms)
> 1: 0x0000000c827759f2 -> 0x0000000c82775aff -> 0x0000000c82775a0e (     0.011 ms)
> 0: 0x0000000c8277a9f2 -> 0x0000000c8277aaff -> 0x0000000c8277aa0d (     0.011 ms)
> 2: 0x0000000c8278f3f1 -> 0x0000000c8278f300 -> 0x0000000c8278f40e (    -0.010 ms)
> 0: 0x0000000c82785ff2 -> 0x0000000c82784300 -> 0x0000000c8278600d (    -0.309 ms)
> 
> After the proposed patch applied the test runs
> correctly (~2 hours of testing with a tool above without fails)

2 hours seems like an incredibly small amount of time given that the
existing workaround was believed to be correct. Run it continuously
for a couple of weeks on several different machines with varying
workloads and less us know the outcome.

Thanks,

	M.

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