15efb47dc5
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 do that because of seqcount
protection.
Use ktime_get_mono_fast_ns() instead which is lock safe for such
cases.
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 may be slightly suboptimal.
Fixes:
|
||
|---|---|---|
| .. | ||
| Makefile | ||
| clock_ops.c | ||
| common.c | ||
| domain.c | ||
| domain_governor.c | ||
| generic_ops.c | ||
| main.c | ||
| power.h | ||
| qos.c | ||
| runtime.c | ||
| sysfs.c | ||
| trace.c | ||
| wakeirq.c | ||
| wakeup.c | ||