[lttng-dev] [RFC PATCH lttng-modules] Fix: nmi-safe clock on 32-bit systems

[Trent Piepho]

On Thu, 2017-02-09 at 20:51 -0500, mathieu.desnoyersa wrote:
> On 32-bit systems, the current algorithm assume 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.

I tested this on my 32-bit ARM system and it has solved the issue with
timestamp being fixed at zero until the first time the TSC wraps.

I'm not sure how to properly test that NMIs do not generate any reverse
timestamps.


> Fix this by using the non-nmi-safe clock source on 32-bit systems,
> except for x86 systems that support double-word cmpxchg (cmpxchg8b).

Is there a reason to restrict this to x86 systems?  ARM supports 64-bit
cmpxchg too, and indeed that's what I was testing.

> +
>  #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,17,0) \
> +	&& (BITS_PER_LONG == 64 || CONFIG_X86_CMPXCHG64) \
>  	&& !defined(LTTNG_CLOCK_NMI_SAFE_BROKEN))

This fails to compile on ARM, as CONFIG_X86_CMPXCHG64 is not defined.
From what I can see, all ARM have cmpxchg64_local() so I modified this
to allow ARM support, used defined(), etc.

It also appears that even if CONFIG_X86_CMPXCHG64 is not defined on x86,
there is still support via another definition of cmpxchg64_local() using
cmpxchg8b_emu.  Or does this version lack some atomic in the face of NMI
ability that the cmpxchg8b instruction would have?