Re: [PATCH] tapset: add a tapset function for reading epoch time in ARM

[Jey Jay <rjayavrp2 at gmail dot com>]

I have tested with 3.10 kernel on ARM. Till now didn't face any kernel
panic issue.
Please guide me whether I can proceed or explore other options for
collecting function execution time.



On Thu, Jun 12, 2014 at 8:51 PM, Josh Stone <jistone@redhat.com> wrote:
> On 06/12/2014 08:10 AM, David Smith wrote:
>> On 06/12/2014 09:57 AM, Josh Stone wrote:
>>> 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.
>>
>> The following kernel commit converted xtime_lock/timekeeper_seq from a
>> seqlock into a seqcount. It now might be possible for systemtap to call
>> the kernel's gettimeofdayns()/do_gettimeofday() here without a
>> context/locking issue. This kernel commit entered the kernel in version
>> 3.10.
>>
>> ====
>> commit 9a7a71b1d0968fc2bd602b7481cde1d4872e01ff
>> Author: Thomas Gleixner <tglx@linutronix.de>
>> Date:   Thu Feb 21 22:51:38 2013 +0000
>>
>>     timekeeping: Split timekeeper_lock into lock and seqcount
>>
>>     We want to shorten the seqcount write hold time. So split the seqlock
>>     into a lock and a seqcount.
>>
>>     Open code the seqwrite_lock in the places which matter and drop the
>>     sequence counter update where it's pointless.
>>
>>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>>     [jstultz: Merge fixups from CLOCK_TAI collisions]
>>     Signed-off-by: John Stultz <john.stultz@linaro.org>
>> ====
>
> The window might be narrower, but I think read_seqcount_retry will still
> deadloop us if we try to read between write_seqcount_begin/end.
>