linux-kernel - Re: [PATCH v2 1/3] timekeeping: Introduce fast accessor to clock tai

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: <20220427132205.386be5e6@gandalf.local.home>
Date:   Wed, 27 Apr 2022 13:22:05 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Kurt Kanzenbach <kurt@...utronix.de>
Cc:     John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Richard Cochran <richardcochran@...il.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] timekeeping: Introduce fast accessor to clock
 tai

On Wed, 27 Apr 2022 11:27:59 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> I'm able to trigger this on x86 64bit too.
> 
> One thing I noticed, is that the two numbers I have (from a different
> trace, but very similar to the above)
> 
> $ printf "%llx\n" 498151194674148935
> 6e9c9df4afd3647
> 
> $ printf "%llx\n" 1651072699280995911
> 16e9c9df4afd3647
> 
> That is, the last nibble either is 0 or 1, causing the change?
> 
> 06e9c9df4afd3647
> 16e9c9df4afd3647
> 
> The numbers are the same except for that last nibble.

And I just realized what the issue is. The ring buffer only allows for 59
bits of timestamp, as there's times it needs to inject a timestamp into the
buffer, which is 16 bytes, and the first 5 bits are meta data, leaving 59
bits for the timestamp. Since no timestamp came close to that before this
timer, everything worked.

Thus, when a full timestamp is injected, it takes off the 5 MSBs of the
timestamp (which took off that 1) and that is what is happening.

I can see if I can play some games to detect this and replace the top 5
bits with the saved timestamp at the head of the sub buffer.

-- Steve