linux-kernel - Re: [PATCH] timekeeping: Add tracepoints for xtime changes

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

Date:	Mon, 01 Apr 2013 15:58:47 -0600
From:	David Ahern <dsahern@...il.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] timekeeping: Add tracepoints for xtime changes - v2

On 4/1/13 12:55 PM, John Stultz wrote:
>
> Sorry I missed this, I no longer receive emails at that address.

Noted. I'll update the address on future versions (and dropped the IBM 
one from this thread).

>     diff --git a/include/trace/events/timekeeping.h
>     b/include/trace/events/timekeeping.h
>     new file mode 100644
>     index 0000000..ff7a631
>     --- /dev/null
>     +++ b/include/trace/events/timekeeping.h
>     @@ -0,0 +1,51 @@
>     +#undef TRACE_SYSTEM
>     +#define TRACE_SYSTEM timekeeping
>     +
>     +#if !defined(_TRACE_TIMEKEEP_H) || defined(TRACE_HEADER_MULTI_READ)
>     +#define _TRACE_TIMEKEEP_H
>     +
>     +#include <linux/tracepoint.h>
>     +#include <linux/time.h>
>     +
>     +DECLARE_EVENT_CLASS(xtime_template,

> So xtime is becoming more of a historical reference in the code. Should
> this maybe be timespec_template? Or timeupdate_template?

What I want is to track updates (user, ntpd, other) to the timespec 
returned for gettimeofday (or, per the comment in that function, 
getnstimeofday). The event will have the new value for that timekeeper 
and the perf_clock timestamp as well so I can update the correlation.

I'm fine with calling it timespec_template. No religion on the names, 
only the feature.

--8<--

> This all looks reasonable. Though do we need to be more explicit in what
> we're tracing here? ie: CLOCK_REALTIME timestamps?

The tracepoints don't care about the what and the tp names follow the 
convention of trace_<function_name> so you know where it is triggering.

>
> I'd someday eventually like to rework the timekeeping core to be mostly
> ktime_t based, building time in a more logical method up from
> CLOCK_MONOTONIC rather then using CLOCK_REALTIME as our base and
> subtracting time from that. I'm just worried about what sort of
> constraints these tracepoints may put on a larger rework in the future.

Understood. And my comment above is not going to help -- ie., telling 
perf specific tracepoints which include function names. Should I 
consolidate this into a single trace_tod_update() that gets invoked in 
various places? The locations can move without affecting perf. I just 
want the tod update; where it happens should not matter.

David

David
--
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/