Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3529129pxf; Mon, 15 Mar 2021 11:35:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtBldcfQvjggSaLKSVv+qgaOcFXNwmwVIt/JCI02raog2XA7IXzsLCCgp7DVEYwdLXkiG/ X-Received: by 2002:a17:907:1614:: with SMTP id hb20mr10103692ejc.77.1615833300685; Mon, 15 Mar 2021 11:35:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615833300; cv=none; d=google.com; s=arc-20160816; b=gu3Pah27a1lK5uLYEUyfCgPakGHuS26+ca3OSa5kc0gmJgAIBRX9Lli4eDlhgLvpDJ rKNBfcbNQzUjBogqNu94+aRp+/C5AqkWaqYNNA9j3XTVKD+sk2QVUnzAJ7Q+boepGduy gLgK2N3kN3/iAMfp8AeJH3Eg7Aolm5np+syqQl4c6f1jf15bdJ9QAbje0LYrBtGnhIzU jRdepzZFjJxTSWu/hZU4OmXWCjKjAzURHK+kBpEPVzdsGe5ll5qgXVMyxLPmvgv4n5AY OYg92z3NxnkShG4FQyZgXZzuTCyT4e9NBm9ecNrmtjtDHlDQ/Y5CobXe6N2Cw4iYQI52 58ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=yn8l42p6/wAUuFWqXJDIdKvIysIIIkZRWMUyjwgpvPY=; b=ZXu2uh1E+ILUghp83FZAtWQI9wWsmJxAESlhQgias48d+D8PY7DHwLAkDwr/6jx+6u JelmvuNibJ+Bz7XbW96TxkLa/yGslnVexXGb/5bYjQP25bPieQfvX+TV3WkwxnA9AfNT PZ0BSdwF/tkkyKCh4pmEmUPyJ/waHVnJCSpct48tGak973ecj4bCD2viNCLRw8fs1txZ RZjeeOeeKqg4licv+mMNJj/1HBPJHAM+yACnuW9LwO7Z7qNaKxZ3H5+Pzep1BvKSwno5 QSWT5jfzw/EklW2NBaa2VYAxA87BPuonv/MGhz0l+mR1R2FzTOfNC84IixI2MdgruQyG eQZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=smH6Usi+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si11144799ejd.152.2021.03.15.11.34.38; Mon, 15 Mar 2021 11:35:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=smH6Usi+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238813AbhCOOoV (ORCPT + 99 others); Mon, 15 Mar 2021 10:44:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:50530 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231553AbhCOODv (ORCPT ); Mon, 15 Mar 2021 10:03:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 601F064EF3; Mon, 15 Mar 2021 14:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615817030; bh=ix72ziC2gyY3wXIxbSgf7FlFZU3dBFsG5k9aDmuzf3E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=smH6Usi+pDMhBc8yDr+wVTjZ/uLW8bsRNZa1AcE0YFcLxq+upQ8FAP4qLZci7eWRN JQTl2/0v7o8PBNYvEYi7K+TkWqqFs91T3+A3qL9fqTk65w5FrTQ5oJTdniF5C2Tjfu /0AmCT8HgVF46hHqsODvw0JGj73KfcFsxYlHyKQo= From: gregkh@linuxfoundation.org To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikael Beckius , Thomas Gleixner , Anna-Maria Behnsen , Ingo Molnar , Sasha Levin Subject: [PATCH 5.10 255/290] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() Date: Mon, 15 Mar 2021 14:55:48 +0100 Message-Id: <20210315135550.630952534@linuxfoundation.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210315135541.921894249@linuxfoundation.org> References: <20210315135541.921894249@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Greg Kroah-Hartman From: Anna-Maria Behnsen [ Upstream commit 46eb1701c046cc18c032fa68f3c8ccbf24483ee4 ] hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: 5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Reported-by: Mikael Beckius Suggested-by: Thomas Gleixner Tested-by: Mikael Beckius Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210223160240.27518-1-anna-maria@linutronix.de Signed-off-by: Sasha Levin --- kernel/time/hrtimer.c | 60 ++++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 21 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 387b4bef7dd1..4416f5d72c11 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -546,8 +546,11 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base, } /* - * Recomputes cpu_base::*next_timer and returns the earliest expires_next but - * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram. + * Recomputes cpu_base::*next_timer and returns the earliest expires_next + * but does not set cpu_base::*expires_next, that is done by + * hrtimer[_force]_reprogram and hrtimer_interrupt only. When updating + * cpu_base::*expires_next right away, reprogramming logic would no longer + * work. * * When a softirq is pending, we can ignore the HRTIMER_ACTIVE_SOFT bases, * those timers will get run whenever the softirq gets handled, at the end of @@ -588,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_ return expires_next; } +static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base) +{ + ktime_t expires_next, soft = KTIME_MAX; + + /* + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. + */ + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); + /* + * Update the soft expiry time. clock_settime() might have + * affected it. + */ + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; + } + + return expires_next; +} + static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base) { ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset; @@ -628,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { ktime_t expires_next; - /* - * Find the current next expiration time. - */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { - /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. - */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; - } + expires_next = hrtimer_update_next_event(cpu_base); if (skip_equal && expires_next == cpu_base->expires_next) return; @@ -1644,8 +1662,8 @@ void hrtimer_interrupt(struct clock_event_device *dev) __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD); - /* Reevaluate the clock bases for the next expiry */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); + /* Reevaluate the clock bases for the [soft] next expiry */ + expires_next = hrtimer_update_next_event(cpu_base); /* * Store the new expiry value so the migration code can verify * against it. -- 2.30.1