On Wed, Jan 30, 2019 at 6:26 PM Vincent Guittot <vincent.guit...@linaro.org> wrote: > > A deadlock has been seen when swicthing clocksources which use PM runtime. > The call path is: > change_clocksource > ... > write_seqcount_begin > ... > timekeeping_update > ... > sh_cmt_clocksource_enable > ... > rpm_resume > pm_runtime_mark_last_busy > ktime_get > do > read_seqcount_begin > while read_seqcount_retry > .... > write_seqcount_end > > Although we should be safe because we haven't yet changed the clocksource > at that time, we can't because of seqcount protection. > > Use ktime_get_mono_fast_ns() instead which is lock safe for such case > > With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be > monotonic across an update and as a result can goes backward. According to > update_fast_timekeeper() description: "In the worst case, this can > result is a slightly wrong timestamp (a few nanoseconds)". For > PM runtime autosuspend, this means only that the suspend decision can > be slightly sub optimal. > > Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") > Reported-by: Biju Das <biju....@bp.renesas.com> > Signed-off-by: Vincent Guittot <vincent.guit...@linaro.org> > --- > > Hi Rafael, > > Sorry, I sent the version with the typo mistake that generated the > compilation error > reported by kbuild-test-robot > > This version doesn't have the typo.
OK, I've applied this one, thanks!