linux-kernel - Re: [PATCH 0/2] timekeeping: cleanup _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]

Message-ID: <CAK8P3a3nnrm0pebbA2fx9dHYwH7vkYWuJAQVWRzzQikOkXYqcQ@mail.gmail.com>
Date:   Tue, 25 Jun 2019 12:18:01 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/2] timekeeping: cleanup _fast_ variety of functions

On Tue, Jun 25, 2019 at 10:19 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hi Thomas,
>
> When Arnd and I discussed this prior, he thought it best that I separate
> these two commits out into a separate patchset, because they might
> require additional discussion or consideration from you. They seem
> straightforward enough to me, but if deliberations require me to make
> some tweaks, I'm happy to do so.

One concern I had was whether we want to replace 'fast' with something
else, such as 'in_nmi' that might be less confusing.  The current naming
might be easy to confuse between 'fast' and 'coarse'.

Another point might be whether we actually need more than one
kind of accessor for each time domain, given how rarely these are
used. In theory we could have the full set of combinations of fast:
monotonic/real/boottime/raw (but not clocktai) with ktime_t/ns/seconds/ts64
for 16 versions.  We currently have four, and you are adding another
four, but not the final eight. I'm not saying this is wrong, but
it feels a bit arbitrary and could use an explanation why you feel that
is the right subset.

For coarse, we have ktime_t and ts64. The _seconds() accessors are
coarse by definition, but we probably don't want to add _ns().
We also don't have the combination of 'raw' with 'coarse' or 'seconds',
as that seems to have no use case.

      Arnd