From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0843DEB64DD for ; Sun, 13 Aug 2023 03:16:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229807AbjHMDQ1 (ORCPT ); Sat, 12 Aug 2023 23:16:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229862AbjHMDQ0 (ORCPT ); Sat, 12 Aug 2023 23:16:26 -0400 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46398E8 for ; Sat, 12 Aug 2023 20:16:29 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id ca18e2360f4ac-790c24db283so95630639f.3 for ; Sat, 12 Aug 2023 20:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1691896588; x=1692501388; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+6LNT5bSHHNBOuFl8YfqtswMbbK7njZVoFvNZ5Ia9qk=; b=dsa/MAOJWu1QG13jnmnZg1cN+6bd9MwyaNF811fDr0brwpNyno7qkK8WnZ0KgP2PJx YPVmjRjL3Ne/eSbApgagUehcVrJZZS6JVyY9wZwKsNgsTRSjsvfIlGggDMKqgoOVR5+o 4gO9SVu9NKdUmm+GoemCiBlJQmh8fksf3PHYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691896588; x=1692501388; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+6LNT5bSHHNBOuFl8YfqtswMbbK7njZVoFvNZ5Ia9qk=; b=YoAIPT5bZiqLTlNzVnpcF+yMn2vmZ1me8OjBlwf5At6QON05fgcmBx+jUOAebkREKu wPoe8zBHwWczhupkPJWi5chCpjNYovzqRXZkG8l7OIMEeyNJ0/MBoSGVT3A67qyncVN6 PkXYzUJrnq7iBaoFdRvS1Tjdza/w0JTUisoO20wcyWc6NPeBP7++rAcJ0KLUzLDd0Crg x9AE4RhSB4/HhC93weBLwPZCHSG+xaOSjUOlZC303/z2EcpaWX+AViws0Gbrix7mFhee mZ77SXI3tIiBS+0scCo5joXghAKYiB5uz3+bt+LCYt9E43FQf1zgqeSo0df52ICU41sB X0hg== X-Gm-Message-State: AOJu0YxcpXv3CMMcUZRNF+FtS/AZni0KqcmFinwwkNi7O1gI7Ht27vnQ M0UBg+6BuUoX6sidqAb1BeKk9LtM0B9ucvypyBQ= X-Google-Smtp-Source: AGHT+IE/uB9RjK7lfEraw/mZgrJt5jNpIg9Vv67k5QV9Q1vc1Ufub5yGfD+gRyNyhDsGkgO8uWr3Ng== X-Received: by 2002:a5e:aa19:0:b0:790:adce:d553 with SMTP id s25-20020a5eaa19000000b00790adced553mr8346322ioe.21.1691896588277; Sat, 12 Aug 2023 20:16:28 -0700 (PDT) Received: from joelboxx5.c.googlers.com.com (254.82.172.34.bc.googleusercontent.com. [34.172.82.254]) by smtp.gmail.com with ESMTPSA id em6-20020a0566384da600b0042b0a6d899fsm2106263jab.60.2023.08.12.20.16.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Aug 2023 20:16:27 -0700 (PDT) From: "Joel Fernandes (Google)" To: stable@vger.kernel.org Cc: Guenter Roeck , Steven Rostedt , Frederic Weisbecker , "Paul E . McKenney" , Thomas Gleixner , Joel Fernandes Subject: [PATCH 5.15 3/3] timers/nohz: Last resort update jiffies on nohz_full IRQ entry Date: Sun, 13 Aug 2023 03:16:20 +0000 Message-ID: <20230813031620.2218302-3-joel@joelfernandes.org> X-Mailer: git-send-email 2.41.0.640.ga95def55d0-goog In-Reply-To: <20230813031620.2218302-1-joel@joelfernandes.org> References: <20230813031620.2218302-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Frederic Weisbecker [ Upstream commit 53e87e3cdc155f20c3417b689df8d2ac88d79576 ] When at least one CPU runs in nohz_full mode, a dedicated timekeeper CPU is guaranteed to stay online and to never stop its tick. Meanwhile on some rare case, the dedicated timekeeper may be running with interrupts disabled for a while, such as in stop_machine. If jiffies stop being updated, a nohz_full CPU may end up endlessly programming the next tick in the past, taking the last jiffies update monotonic timestamp as a stale base, resulting in an tick storm. Here is a scenario where it matters: 0) CPU 0 is the timekeeper and CPU 1 a nohz_full CPU. 1) A stop machine callback is queued to execute somewhere. 2) CPU 0 reaches MULTI_STOP_DISABLE_IRQ while CPU 1 is still in MULTI_STOP_PREPARE. Hence CPU 0 can't do its timekeeping duty. CPU 1 can still take IRQs. 3) CPU 1 receives an IRQ which queues a timer callback one jiffy forward. 4) On IRQ exit, CPU 1 schedules the tick one jiffy forward, taking last_jiffies_update as a base. But last_jiffies_update hasn't been updated for 2 jiffies since the timekeeper has interrupts disabled. 5) clockevents_program_event(), which relies on ktime_get(), observes that the expiration is in the past and therefore programs the min delta event on the clock. 6) The tick fires immediately, goto 3) 7) Tick storm, the nohz_full CPU is drown and takes ages to reach MULTI_STOP_DISABLE_IRQ, which is the only way out of this situation. Solve this with unconditionally updating jiffies if the value is stale on nohz_full IRQ entry. IRQs and other disturbances are expected to be rare enough on nohz_full for the unconditional call to ktime_get() to actually matter. Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Tested-by: Paul E. McKenney Link: https://lore.kernel.org/r/20211026141055.57358-2-frederic@kernel.org Signed-off-by: Joel Fernandes (Google) --- kernel/softirq.c | 3 ++- kernel/time/tick-sched.c | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/softirq.c b/kernel/softirq.c index 322b65d45676..41f470929e99 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -595,7 +595,8 @@ void irq_enter_rcu(void) { __irq_enter_raw(); - if (is_idle_task(current) && (irq_count() == HARDIRQ_OFFSET)) + if (tick_nohz_full_cpu(smp_processor_id()) || + (is_idle_task(current) && (irq_count() == HARDIRQ_OFFSET))) tick_irq_enter(); account_hardirq_enter(current); diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 5786e2794ae1..7f5310d1a4d6 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -1420,6 +1420,13 @@ static inline void tick_nohz_irq_enter(void) now = ktime_get(); if (ts->idle_active) tick_nohz_stop_idle(ts, now); + /* + * If all CPUs are idle. We may need to update a stale jiffies value. + * Note nohz_full is a special case: a timekeeper is guaranteed to stay + * alive but it might be busy looping with interrupts disabled in some + * rare case (typically stop machine). So we must make sure we have a + * last resort. + */ if (ts->tick_stopped) tick_nohz_update_jiffies(now); } -- 2.41.0.640.ga95def55d0-goog