linux-kernel - Re: Question about ktime_get_mono_fast

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, 13 Oct 2022 19:23:24 -0700
From:   John Stultz <jstultz@...gle.com>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Hao Luo <haoluo@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: Question about ktime_get_mono_fast_ns() non-monotonic behavior

On Thu, Oct 13, 2022 at 7:15 PM John Stultz <jstultz@...gle.com> wrote:
>
> On Thu, Oct 13, 2022 at 6:29 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> >
> > On Thu, Oct 13, 2022 at 5:03 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> > >
> > > On Wed, Oct 12, 2022 at 8:07 PM John Stultz <jstultz@...gle.com> wrote:
> > > >
> > > > On Wed, Oct 12, 2022 at 8:02 PM John Stultz <jstultz@...gle.com> wrote:
> > > > > On Mon, Sep 26, 2022 at 2:18 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> > > > > So I think it reasonable to say its bounded by approximately  2 *
> > > > > NSEC_PER_SEC/HZ +/- 11%.
> > > >
> > > > Sorry, this should be 2*NSEC_PER_SEC/HZ * 0.11
> > >
> > > Thanks so much for the detailed response :)
> > >
> > > IIUC this error bound is in ns. So on a 2 GHz cpu the bound is 0.11 ns
> > > (essentially 0)? I feel like I miscalculated, this error bound is too
> > > good to be true.
> >
> > Never mind, I thought HZ is the cpu speed for some reason. It's the
> > number of jiffies per second, right?
>
> Correct.
>
> > So if HZ is 1000, the error bound is actually ~2 ms, which is very
> > large considering that the unit is ns.
>
> Uh, for HZ=1000, I think it's closer to 220us, but yes, for HZ=100 2.2ms.

And again, it has been awhile since I've been deep in this code, so
I'd not be surprised if I'm missing something and the worst case may
be larger (things like SMIs or virtualization stalling the timekeeping
update for longer than a tick).  So no promises, but this feels pretty
close to the expected bound. If you can't handle time inconsistencies,
you need to use the normal locked accessors.

thanks
-john