linux-kernel - Re: [PATCH] rust: time: New module for timekeeping functions

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:   Wed, 22 Feb 2023 01:24:53 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Asahi Lina <lina@...hilina.net>, Boqun Feng <boqun.feng@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        John Stultz <jstultz@...gle.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org,
        rust-for-linux@...r.kernel.org, asahi@...ts.linux.dev,
        Heghedus Razvan <heghedus.razvan@...tonmail.com>
Subject: Re: [PATCH] rust: time: New module for timekeeping functions

Miguel!

On Tue, Feb 21 2023 at 23:29, Miguel Ojeda wrote:
> On Tue, Feb 21, 2023 at 7:45 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> But xb abd xr are the same datatype because they represent a time delta.
>
> In principle, one could also have different duration types too. For
> instance, C++'s `std::chrono::duration` type is parametrized on the
> representation type and the tick period, and thus an operation between
> two time points like t1 - t0 returns a duration type that depends on
> the type of the time points, i.e. which clock they were obtained from.

Correct, but for practical purposes I'd assume that the timestamps
retrieved via ktime_get*() have the same granularity, i.e. 1ns.

TBH, that's not entirely correct because:

    - the underlying hardware clocksource might not have a 1ns
      resolution

    - the CLOCK_*_COARSE implementations are only advanced once per
      tick, but are executing significantly faster because they avoid
      the hardware counter access.

But that's an assumption which has proven to be workable and correct
with the full zoo of hardware supported by the kernel.

The point is that all CLOCK_* variants, except CLOCK_REALTIME and
CLOCK_TAI are guaranteed to never go backwards.

CLOCK_REALTIME and CLOCK_TAI are special as they can be set by user
space and CLOCK_REALTIME has the extra oddities of leap seconds.  But
that's a well understood issue and is not specific to the kernel.

Back to time deltas (or duration types). Independent of the above it
might make sense to be type strict about these as well. Especially if we
go one step further and have timers based on CLOCK_* which need to be
armed by either timestamps for absolute expiry or time deltas for
relative to now expiry. I definitely can see a point for requiring
matching time delta types there.

That said, I have no strong opinions about this particular detail and
leave it to the Rusties to agree on something sensible.

Thanks,

        tglx