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

[Will Deacon]

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 at arm.com>
> Cc: Josh Cartwright <joshc at codeaurora.org>
> Signed-off-by: Stephen Boyd <sboyd at 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 at arm.com>

Will