linux-kernel - Re: [PATCH v10 3/7] x86/time: read_boot

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:   Mon, 18 Jun 2018 11:44:57 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Pavel Tatashin <pasha.tatashin@...cle.com>
Cc:     Steven Sistare <steven.sistare@...cle.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        John Stultz <john.stultz@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dou Liyang <douly.fnst@...fujitsu.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>, prarit@...hat.com,
        Feng Tang <feng.tang@...el.com>,
        Petr Mladek <pmladek@...e.com>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: [PATCH v10 3/7] x86/time: read_boot_clock64() implementation

On Mon, Jun 18, 2018 at 11:42 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> On Fri, Jun 15, 2018 at 8:48 PM Pavel Tatashin <pasha.tatashin@...cle.com> wrote:
> >
> > read_boot_clock64() returns time of when system was started. Now, that
> > early boot clock is going to be available on x86 it is possible to
> > implement x86 specific version of read_boot_clock64() that takes advantage
> > of this new feature.
>

Oops, sorry for previous empty mail.

> > +void __init read_boot_clock64(struct timespec64 *now, struct timespec64 *ts)
> > +{
> > +       u64 ns_boot = sched_clock_cpu(smp_processor_id());
> > +       bool valid_clock;
> > +       u64 ns_now;
> > +
> > +       ns_now = timespec64_to_ns(now);
> > +       valid_clock = ns_boot && timespec64_valid_strict(now) &&
> > +                       (ns_now > ns_boot);
> > +
>


> > +       if (!valid_clock)

Are we expecting more often clock to be non-valid?
Perhaps change to positive conditional?

> > +               *ts = (struct timespec64){0, 0};

I dunno if additional variable would be better for readability, like

struct timespec64 null_ts = {0,0};
...
*ts = null_ts;

> > +       else
> > +               *ts = ns_to_timespec64(ns_now - ns_boot);

But I'm fine as long as Thomas is okay with this code.

> > +}


-- 
With Best Regards,
Andy Shevchenko