aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pwm/pwm-stm32.c
diff options
context:
space:
mode:
authorPaul E. McKenney <[email protected]>2024-08-05 18:44:43 +0000
committerPaul E. McKenney <[email protected]>2024-10-11 16:31:21 +0000
commit9861f7f66f98a6358c944c17a5d4acd07abcb1a7 (patch)
tree89823d6cbadcb42ffe6e08408f25007ae2cf9799 /drivers/pwm/pwm-stm32.c
parentLinux 6.12-rc1 (diff)
downloadkernel-9861f7f66f98a6358c944c17a5d4acd07abcb1a7.tar.gz
kernel-9861f7f66f98a6358c944c17a5d4acd07abcb1a7.zip
locking/csd-lock: Switch from sched_clock() to ktime_get_mono_fast_ns()
Currently, the CONFIG_CSD_LOCK_WAIT_DEBUG code uses sched_clock() to check for excessive CSD-lock wait times. This works, but does not guarantee monotonic timestamps on x86 due to the sched_clock() function's use of the rdtsc instruction, which does not guarantee ordering. This means that, given successive calls to sched_clock(), the second might return an earlier time than the second, that is, time might seem to go backwards. This can (and does!) result in false-positive CSD-lock wait complaints claiming almost 2^64 nanoseconds of delay. Therefore, switch from sched_clock() to ktime_get_mono_fast_ns(), which does guarantee monotonic timestamps via the rdtsc_ordered() function, which as the name implies, does guarantee ordered timestamps, at least in the absence of calls from NMI handlers, which are not involved in this code path. Signed-off-by: Paul E. McKenney <[email protected]> Reviewed-by: Rik van Riel <[email protected]> Cc: Neeraj Upadhyay <[email protected]> Cc: Leonardo Bras <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: "Peter Zijlstra (Intel)" <[email protected]>
Diffstat (limited to 'drivers/pwm/pwm-stm32.c')
0 files changed, 0 insertions, 0 deletions