LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: tip-bot for Thomas Gleixner <tipbot@zytor.com> To: linux-tip-commits@vger.kernel.org Cc: frederic@kernel.org, mike.marciniszyn@intel.com, linux-kernel@vger.kernel.org, hpa@zytor.com, kaike.wan@intel.com, tglx@linutronix.de, dennis.dalessandro@intel.com, fweisbec@gmail.com, anna-maria@linutronix.de, john.fleck@intel.com, ira.weiny@intel.com, mingo@kernel.org, peterz@infradead.org Subject: [tip:timers/urgent] tick/sched: Do not mess with an enqueued hrtimer Date: Thu, 26 Apr 2018 05:57:45 -0700 [thread overview] Message-ID: <tip-1f71addd34f4c442bec7d7c749acc1beb58126f2@git.kernel.org> (raw) In-Reply-To: <alpine.DEB.2.21.1804242119210.1597@nanos.tec.linutronix.de> Commit-ID: 1f71addd34f4c442bec7d7c749acc1beb58126f2 Gitweb: https://git.kernel.org/tip/1f71addd34f4c442bec7d7c749acc1beb58126f2 Author: Thomas Gleixner <tglx@linutronix.de> AuthorDate: Tue, 24 Apr 2018 21:22:18 +0200 Committer: Thomas Gleixner <tglx@linutronix.de> CommitDate: Thu, 26 Apr 2018 14:53:32 +0200 tick/sched: Do not mess with an enqueued hrtimer Kaike reported that in tests rdma hrtimers occasionaly stopped working. He did great debugging, which provided enough context to decode the problem. CPU 3 CPU 2 idle start sched_timer expires = 712171000000 queue->next = sched_timer start rdmavt timer. expires = 712172915662 lock(baseof(CPU3)) tick_nohz_stop_tick() tick = 716767000000 timerqueue_add(tmr) hrtimer_set_expires(sched_timer, tick); sched_timer->expires = 716767000000 <---- FAIL if (tmr->expires < queue->next->expires) hrtimer_start(sched_timer) queue->next = tmr; lock(baseof(CPU3)) unlock(baseof(CPU3)) timerqueue_remove() timerqueue_add() ts->sched_timer is queued and queue->next is pointing to it, but then ts->sched_timer.expires is modified. This not only corrupts the ordering of the timerqueue RB tree, it also makes CPU2 see the new expiry time of timerqueue->next->expires when checking whether timerqueue->next needs to be updated. So CPU2 sees that the rdma timer is earlier than timerqueue->next and sets the rdma timer as new next. Depending on whether it had also seen the new time at RB tree enqueue, it might have queued the rdma timer at the wrong place and then after removing the sched_timer the RB tree is completely hosed. The problem was introduced with a commit which tried to solve inconsistency between the hrtimer in the tick_sched data and the underlying hardware clockevent. It split out hrtimer_set_expires() to store the new tick time in both the NOHZ and the NOHZ + HIGHRES case, but missed the fact that in the NOHZ + HIGHRES case the hrtimer might still be queued. Use hrtimer_start(timer, tick...) for the NOHZ + HIGHRES case which sets timer->expires after canceling the timer and move the hrtimer_set_expires() invocation into the NOHZ only code path which is not affected as it merily uses the hrtimer as next event storage so code pathes can be shared with the NOHZ + HIGHRES case. Fixes: d4af6d933ccf ("nohz: Fix spurious warning when hrtimer and clockevent get out of sync") Reported-by: "Wan Kaike" <kaike.wan@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Frederic Weisbecker <frederic@kernel.org> Cc: "Marciniszyn Mike" <mike.marciniszyn@intel.com> Cc: Anna-Maria Gleixner <anna-maria@linutronix.de> Cc: linux-rdma@vger.kernel.org Cc: "Dalessandro Dennis" <dennis.dalessandro@intel.com> Cc: "Fleck John" <john.fleck@intel.com> Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: "Weiny Ira" <ira.weiny@intel.com> Cc: "linux-rdma@vger.kernel.org" Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804241637390.1679@nanos.tec.linutronix.de Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804242119210.1597@nanos.tec.linutronix.de --- kernel/time/tick-sched.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 646645e981f9..d31bec177fa5 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -804,12 +804,12 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) return; } - hrtimer_set_expires(&ts->sched_timer, tick); - - if (ts->nohz_mode == NOHZ_MODE_HIGHRES) - hrtimer_start_expires(&ts->sched_timer, HRTIMER_MODE_ABS_PINNED); - else + if (ts->nohz_mode == NOHZ_MODE_HIGHRES) { + hrtimer_start(&ts->sched_timer, tick, HRTIMER_MODE_ABS_PINNED); + } else { + hrtimer_set_expires(&ts->sched_timer, tick); tick_program_event(tick, 1); + } } static void tick_nohz_retain_tick(struct tick_sched *ts)
prev parent reply other threads:[~2018-04-26 12:59 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <3F128C9216C9B84BB6ED23EF16290AFB634C8C87@CRSMSX101.amr.corp.intel.com> 2018-04-23 12:53 ` hrtimer (rdmavt RNR timer) was lost Thomas Gleixner 2018-04-23 13:22 ` Wan, Kaike 2018-04-23 13:35 ` Thomas Gleixner 2018-04-24 14:54 ` Thomas Gleixner 2018-04-24 16:48 ` Frederic Weisbecker 2018-04-24 19:22 ` [PATCH] tick/sched: Do not mess with an enqueued hrtimer Thomas Gleixner 2018-04-25 13:22 ` Frederic Weisbecker 2018-04-25 14:21 ` [tip:timers/urgent] " tip-bot for Thomas Gleixner 2018-04-26 12:56 ` [PATCH] " Wan, Kaike 2018-04-26 12:57 ` tip-bot for Thomas Gleixner [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=tip-1f71addd34f4c442bec7d7c749acc1beb58126f2@git.kernel.org \ --to=tipbot@zytor.com \ --cc=anna-maria@linutronix.de \ --cc=dennis.dalessandro@intel.com \ --cc=frederic@kernel.org \ --cc=fweisbec@gmail.com \ --cc=hpa@zytor.com \ --cc=ira.weiny@intel.com \ --cc=john.fleck@intel.com \ --cc=kaike.wan@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tip-commits@vger.kernel.org \ --cc=mike.marciniszyn@intel.com \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).