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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1906280019460.32342@nanos.tec.linutronix.de>
Date:   Fri, 28 Jun 2019 00:21:01 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Arnd Bergmann <arnd@...db.de>
cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] timekeeping: cleanup _fast_ variety of functions

On Tue, 25 Jun 2019, Arnd Bergmann wrote:
> On Tue, Jun 25, 2019 at 10:19 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > 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.

Can we please just add those which are actually needed. If new code misses
something we can add them anytime later.

Thanks,

	tglx