[PATCH v2] sched_clock: Prevent callers from seeing half-updated data

[john.stultz@linaro.org (John Stultz)]

On 02/17/2014 03:19 AM, Will Deacon wrote:
> On Mon, Feb 10, 2014 at 11:14:35AM +0000, Will Deacon wrote:
>> On Fri, Feb 07, 2014 at 10:28:58PM +0000, Stephen Boyd wrote:
>>> If two sched_clock sources are registered we may end up in a
>>> situation where a call to sched_clock() may be accessing the
>>> epoch cycle count for the old counter and the cycle count for the
>>> new counter. This can lead to confusing results where
>>> sched_clock() values jump and then are reset to 0 (due to the way
>>> the registration function forces the epoch_ns to be 0). Fix this
>>> by reorganizing the registration function to hold the seqlock for
>>> as short a time as possible while we update the clock_data
>>> structure for a new counter. We also put any accumulated time
>>> into epoch_ns instead of resetting the time to 0 so that the clock
>>> doesn't reset after each successful registration.
>>>
>>> Reported-by: Will Deacon <will.deacon@arm.com>
>>> Cc: Josh Cartwright <joshc@codeaurora.org>
>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>> ---
>>>
>>> Changes since v1:
>>>  * Put elapsed time into epoch_ns 
>> Well, this certainly fixes the dmesg prints and the system seems ok once
>> it's booted:
>>
>>   Tested-by: Will Deacon <will.deacon@arm.com>
> Any chance of getting this merged please? I still see the weird timing
> numbers when booting -rc3.


My apologies! I somehow missed your tested-by mail.

I'll queue it up and send it in.

thanks
-john