Messages in this thread | | | Date | Tue, 18 Feb 2014 12:32:45 -0800 | Subject | Re: [PATCH] sched_clock: Prevent callers from seeing half-updated data | From | John Stultz <> |
| |
On Tue, Feb 18, 2014 at 12:20 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Mon, 17 Feb 2014, John Stultz wrote: > >> From: Stephen Boyd <sboyd@codeaurora.org> >> >> The generic sched_clock registration function was previously >> done lockless, due to the fact that it was expected to be called >> only once. However, now there are systems that may register >> multiple sched_clock sources, for which the lack of locking has >> casued problems: >> >> 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. >> >> Cc: Peter Zijlstra <peterz@infradead.org> > > Peter ???
So this is the generic sched_clock work, which Peter really hasn't had much involvement with yet (mostly because its not yet generic enough to work with more then a few arches). But I included him in the CC since I think it would be good to have him following along.
thanks -john
| |