This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] tapset: add a tapset function for reading epoch time in ARM
- From: Josh Stone <jistone at redhat dot com>
- To: Jey Jay <rjayavrp2 at gmail dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sourceware dot org, jeyaraman dot rangasamy at lge dot com
- Date: Thu, 12 Jun 2014 07:57:18 -0700
- Subject: Re: [PATCH] tapset: add a tapset function for reading epoch time in ARM
- Authentication-results: sourceware.org; auth=none
- References: <CAAKGpwRhhQAcCkATd4LAPxFnvH6M99PeCwzD33aVXpSNAmwFVg at mail dot gmail dot com> <20140612103820 dot GE30297 at redhat dot com>
On 06/12/2014 03:38 AM, Frank Ch. Eigler wrote:
> Hi -
>
>> gettimeofday_ns() for ARM is implemented to return a fake value because
>> it depends on get_cycles() which returns 0 in ARM. This patch adds
>> a tapset function which uses getnstimeofday() for collecting epoch time.
>> [...]
>
> (Another way could be to wrap getnstimeofday into a get_cycles()
> emulation function that the normal runtime/time.c code could use.)
>
> Please note that the reason that the other architectures don't just
> call getnstimeofday() or equivalent functions is because these are (or
> have been) unsafe to call from arbitrary probe contexts, such as
> interrupt-related tracepoints, or kprobes triggered from the vicinity
> of the clock functions. It was found to be better to give an
> approximate time from all contexts rather than letting the kernel
> crash from some of them. Please analyze whether this is still an
> issue for you.
Right, see https://sourceware.org/bugzilla/show_bug.cgi?id=2525
The problem was with xtime_lock, now called timekeeper_seq. If a probe
occurs while that write lock is held, then calls getnstimeofday(), it
would loop forever trying to get the read lock. I don't see anything to
make me think this has changed on modern kernels.