Fix: nmi-safe clock on 32-bit systems
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 10 Feb 2017 01:46:44 +0000 (20:46 -0500)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Tue, 14 Feb 2017 21:06:20 +0000 (16:06 -0500)
commit16200240252178bf016a18eddd39be03a3bdca18
tree61d3d6d532fc878e584e3a3bb2cd533a6a3c5368
parentf61eb2851f482baee02bb508aef01f67fdb3fbaf
Fix: nmi-safe clock on 32-bit systems

On 32-bit systems, the algorithm within lttng-modules that ensures the
nmi-safe clock increases monotonically on a CPU assumes to have one
clock read per 32-bit LSB overflow period, which is not guaranteed. It
also has an issue on the first clock reads after module load, because
the initial value for the last LSB is 0. It can cause the time to stay
stuck at the same value for a few seconds at the beginning of the trace,
which is unfortunate for the first trace after module load, because this
is where the offset between realtime and trace_clock is sampled, which
prevents correlation of kernel and user-space traces for that session.

It only affects 32-bit systems with kernels >= 3.17.

Fix this by using the non-nmi-safe clock source on 32-bit systems.

While we are there, remove an implementation-defined c99 behavior
regarding casting u64 to long by using unsigned arithmetic instead:

turn:
  if (((long) now - (long) last) < 0)
into:
  if (U64_MAX / 2 < now - last)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
wrapper/trace-clock.c
wrapper/trace-clock.h
This page took 0.025806 seconds and 4 git commands to generate.