Patch "sched/features: Fix hrtick reprogramming" has been added to the 5.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    sched/features: Fix hrtick reprogramming

to the 5.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     sched-features-fix-hrtick-reprogramming.patch
and it can be found in the queue-5.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 6af62a5e6aeeb4b19daa39997d4360b83362ab6a
Author: Juri Lelli <juri.lelli@xxxxxxxxxx>
Date:   Mon Feb 8 08:35:53 2021 +0100

    sched/features: Fix hrtick reprogramming
    
    [ Upstream commit 156ec6f42b8d300dbbf382738ff35c8bad8f4c3a ]
    
    Hung tasks and RCU stall cases were reported on systems which were not
    100% busy. Investigation of such unexpected cases (no sign of potential
    starvation caused by tasks hogging the system) pointed out that the
    periodic sched tick timer wasn't serviced anymore after a certain point
    and that caused all machinery that depends on it (timers, RCU, etc.) to
    stop working as well. This issues was however only reproducible if
    HRTICK was enabled.
    
    Looking at core dumps it was found that the rbtree of the hrtimer base
    used also for the hrtick was corrupted (i.e. next as seen from the base
    root and actual leftmost obtained by traversing the tree are different).
    Same base is also used for periodic tick hrtimer, which might get "lost"
    if the rbtree gets corrupted.
    
    Much alike what described in commit 1f71addd34f4c ("tick/sched: Do not
    mess with an enqueued hrtimer") there is a race window between
    hrtimer_set_expires() in hrtick_start and hrtimer_start_expires() in
    __hrtick_restart() in which the former might be operating on an already
    queued hrtick hrtimer, which might lead to corruption of the base.
    
    Use hrtick_start() (which removes the timer before enqueuing it back) to
    ensure hrtick hrtimer reprogramming is entirely guarded by the base
    lock, so that no race conditions can occur.
    
    Signed-off-by: Juri Lelli <juri.lelli@xxxxxxxxxx>
    Signed-off-by: Luis Claudio R. Goncalves <lgoncalv@xxxxxxxxxx>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@xxxxxxxxxx>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
    Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
    Link: https://lkml.kernel.org/r/20210208073554.14629-2-juri.lelli@xxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7841e738e38f..2ce61018e33b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -254,8 +254,9 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
 static void __hrtick_restart(struct rq *rq)
 {
 	struct hrtimer *timer = &rq->hrtick_timer;
+	ktime_t time = rq->hrtick_time;
 
-	hrtimer_start_expires(timer, HRTIMER_MODE_ABS_PINNED_HARD);
+	hrtimer_start(timer, time, HRTIMER_MODE_ABS_PINNED_HARD);
 }
 
 /*
@@ -280,7 +281,6 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
 	struct hrtimer *timer = &rq->hrtick_timer;
-	ktime_t time;
 	s64 delta;
 
 	/*
@@ -288,9 +288,7 @@ void hrtick_start(struct rq *rq, u64 delay)
 	 * doesn't make sense and can cause timer DoS.
 	 */
 	delta = max_t(s64, delay, 10000LL);
-	time = ktime_add_ns(timer->base->get_time(), delta);
-
-	hrtimer_set_expires(timer, time);
+	rq->hrtick_time = ktime_add_ns(timer->base->get_time(), delta);
 
 	if (rq == this_rq()) {
 		__hrtick_restart(rq);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e10fb9bf2988..4e490e3db2f8 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -973,6 +973,7 @@ struct rq {
 	call_single_data_t	hrtick_csd;
 #endif
 	struct hrtimer		hrtick_timer;
+	ktime_t 		hrtick_time;
 #endif
 
 #ifdef CONFIG_SCHEDSTATS



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux