Messages in this thread | | | Date | Tue, 18 Feb 2014 21:53:59 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH] sched_clock: Prevent callers from seeing half-updated data |
| |
On Tue, 18 Feb 2014, John Stultz wrote: > 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.
Fair enough. I'll pick it up.
Thanks,
tglx
| |