Files
linuxkit/kernel/patches-4.14.x-rt/0037-0037-hrtimer-Make-remote-enqueue-decision-less-restrictiv.patch
Tiejun Chen ccd9998461 update -rt to 4.14.40-rt30
Signed-off-by: Tiejun Chen <tiejun.china@gmail.com>
2018-05-15 13:46:26 +08:00

39 lines
1.3 KiB
Diff

From 8cdb34edfcfc64ca7dbf397f0f9235f2d8d6762f Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria@linutronix.de>
Date: Wed, 20 Dec 2017 17:13:10 +0100
Subject: [PATCH 037/414] hrtimer: Make remote enqueue decision less
restrictive
The current decision whether a timer can be queued on a remote CPU checks
for timer->expiry <= remote_cpu_base.expires_next.
This is too restrictive because a timer with the same expiry time as an
existing timer will be enqueued on right-hand size of the existing timer
inside the rbtree, i.e. behind the first expiring timer.
So its safe to allow enqueuing timers with the same expiry time as the
first expiring timer on a remote CPU base.
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 35d7d0c8c3d6..1b2866645c83 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -168,7 +168,7 @@ hrtimer_check_target(struct hrtimer *timer, struct hrtimer_clock_base *new_base)
ktime_t expires;
expires = ktime_sub(hrtimer_get_expires(timer), new_base->offset);
- return expires <= new_base->cpu_base->expires_next;
+ return expires < new_base->cpu_base->expires_next;
}
static inline
--
2.17.0