linux-kernel - Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[

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: <alpine.DEB.2.10.1407141100280.4357@nanos>
Date:	Mon, 14 Jul 2014 11:04:39 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to
 CLOCK_MONOTONIC[_RAW]

On Mon, 14 Jul 2014, Peter Zijlstra wrote:
> On Fri, Jul 11, 2014 at 01:45:19PM -0000, Thomas Gleixner wrote:
> > Tracers want a correlated time between the kernel instrumentation and
> > user space. We really do not want to export sched_clock() to user
> > space, so we need to provide something sensible for this.
> > 
> > Using separate data structures with an non blocking sequence count
> > based update mechanism allows us to do that. The data structure
> > required for the readout has a sequence counter and two copies of the
> > timekeeping data.
> > 
> > On the update side:
> > 
> >   tkf->seq++;
> >   smp_wmb();
> >   update(tkf->base[0], tk;
> >   tkf->seq++;
> >   smp_wmb();
> >   update(tkf->base[1], tk;
> > 
> > On the reader side:
> > 
> >   do {
> >      seq = tkf->seq;
> >      smp_rmb();
> >      idx = seq & 0x01;
> >      now = now(tkf->base[idx]);
> >      smp_rmb();
> >   } while (seq != tkf->seq)
> > 
> > So if NMI hits the update of base[0] it will use base[1] which is
> > still consistent. In case of CLOCK_MONOTONIC this can result in
> > slightly wrong timestamps (a few nanoseconds) accross an update. Not a
> > big issue for the intended use case.
> 
> But it breaks monotonicity, right? ;-)

It can in theory, but does it really matter for tracing?
 
> Also, what happens when TSC is not available as a clocksource? There's
> still a metric ton of hardware (including the latest generation HSW)
> that has fucked firmware/TSC.

Well, bad luck then. You end up using hpet or worse, but it's still
your decision whether to base your instrumentation on that or not. For
sane clock sources (i.e. almost anything except TSC) it works
perfectly fine.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/