From patchwork Wed Jun 21 19:36:08 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 111295 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp4599900vqr; Wed, 21 Jun 2023 12:39:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6twg6AJImr+8Jp4TxAh5KUrm35zc6F+JaheIqlFsHr7x1xFCODwCfDP88FHl03qS98z66s X-Received: by 2002:a17:902:c941:b0:1b6:6a73:f12a with SMTP id i1-20020a170902c94100b001b66a73f12amr9339690pla.4.1687376382944; Wed, 21 Jun 2023 12:39:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687376382; cv=none; d=google.com; s=arc-20160816; b=fQdFnERS5PauwaXQHCxhAWtmEY4CV8DSyVr+KWHrfq2rQP+VrYCAiiFZTUNGHiERM1 Y2+ANFWNufCo2bhgccT36fOpe12X/5/X4HqhVA+Ah/GZBtqaXvotyWdgzeq+u7QryRCV roxRUFcLHxBU73kisZJKm84JUvUMs+g0Fnos2+PjCQqP0iy7KQYwLzWjCwHDz1E+wCmV PwDyirHlx4c1M/Iyf7cSChAzthpu/67JhRbwQjdNs5ipP7315nyHDbvVGDoZMoQlKGWf uxSkJxjlhTd8ei2/jY9oE9U39NyUUVWJZz2k2c7Rm51XDETNYwrxqSEy8w+qorA+Reiy kFhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:mime-version:content-transfer-encoding :message-id:subject:cc:to:dkim-signature:dkim-signature:from; bh=nZqMtAcS8VE7tIXvGLTC8A1h+3EE65bl6ekyCp5H6nE=; b=BfyX3gSPZzpJKBZI1ufgQCq8Os/6i5zMkxhelKNjynV132Og17H3BrVC+d9u8qdgcV PIMPXuYx6i/cZac2F41ptZV1TbJwmAtViFRxt0JtA9LkDmRvvMOLtLwNSyNkdIXTr7iI KpcYVMHHL4sw+FyVfMGarvYEdvNc63M3CLW6bz17RW93Fu1jSFPYQ/7e8XQflfBZ3/dL pRBlfxNTk0Q5fQysBzsJhADSXnHLMFCfqnbHY9HqCO/EGTPDk6wGyZGBCQ/hv3DLmet9 82BmuYhZILNCd2f1DDKZ8b1z/QcPeIR9oNDQm7eAo5lqnqHvoO5K4FtsEFov6Hoyt6Hs zJMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=edZtbxQK; dkim=neutral (no key) header.i=@linutronix.de header.b=K4YtI9ys; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d11-20020a170903230b00b001b3f77db81dsi464964plh.514.2023.06.21.12.39.29; Wed, 21 Jun 2023 12:39:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=edZtbxQK; dkim=neutral (no key) header.i=@linutronix.de header.b=K4YtI9ys; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230136AbjFUTgO (ORCPT + 99 others); Wed, 21 Jun 2023 15:36:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230047AbjFUTgM (ORCPT ); Wed, 21 Jun 2023 15:36:12 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 374E61733 for ; Wed, 21 Jun 2023 12:36:11 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1687376168; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nZqMtAcS8VE7tIXvGLTC8A1h+3EE65bl6ekyCp5H6nE=; b=edZtbxQKMlMbfky1+A1uvsHHfJW4mtx+mN+MXCy8mFoMH2gBgQZnFqRYNFssbhcl9ON88z Yah3rwHzhfKdnzuECgNyILiS0ZiCfre3EuTk+oy9nHPo7mIj0NUjRS+EuvlAqMAiuPK1EQ oUgHMGkEkhSfOXlURm3dcGNX4Y8OShRDinE8SOXOZDOR28Luwwhxbm3U8XV0aQGHLnR//Z 21V3rvwnZNRCV8OYi+Qe1NujxaKMIF5Et08orzlZK7xcWYUGZboCvfJCQioC6jeWa5iT0H 8oXC8kqyiHMQqg5npSXM0mLkFlY8yhUr8XPWObRCnD4Zq+XaPJdiBbFCLTrNhg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1687376168; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nZqMtAcS8VE7tIXvGLTC8A1h+3EE65bl6ekyCp5H6nE=; b=K4YtI9ys6WQI2Pyd2oja4BYr1EH3zLzFlQ6DB91LbOWMGb7DribLaS7pWXIlr9h5/MV75K Hcu9jB2RvjRb1wAg== To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, x86@kernel.org Subject: [GIT pull] timers/urgent for v6.4 Message-ID: <168737611661.277769.2194490737572202840.tglx@xen13> MIME-Version: 1.0 Date: Wed, 21 Jun 2023 21:36:08 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769342378026237485?= X-GMAIL-MSGID: =?utf-8?q?1769342378026237485?= Linus, please pull the latest timers/urgent branch from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-2023-06-21 up to: 13bb06f8dd42: tick/common: Align tick period during sched_timer setup A single regression fix for a regression fix: For a long time the tick was aligned to clock MONOTONIC so that the tick event happened at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0. At some point this changed as the refined jiffies clocksource which is used during boot before the TSC or other clocksources becomes usable, was adjusted with a boot offset, so that time 0 is closer to the point where the kernel starts. This broke the assumption in the tick code that when the tick setup happens early on ktime_get() will return a multiple of nanoseconds per tick. As a consequence applications which aligned their periodic execution so that it does not collide with the tick were not longer guaranteed that the tick period starts from time 0. The fix for this regression was to realign the tick when it is initially set up to a multiple of tick periods. That works as long as the underlying tick device supports periodic mode, but breaks under certain conditions when the tick device supports only one shot mode. Depending on the offset, the alignment delta to clock MONOTONIC can get in a range where the minimal programming delta of the underlying clock event device is larger than the calculated delta to the next tick. This results in a boot hang as the tick code tries to play catch up, but as the tick never fires jiffies are not advanced so it keeps trying for ever. Solve this by moving the tick alignement into the NOHZ / HIGHRES enablement code because at that point it is guaranteed that the underlying clocksource is high resolution capable and not longer depending on the tick. This is far before user space starts, so at the point where applications try to align their timers, the old behaviour of the tick happening at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0 is restored. Thanks, tglx ------------------> Thomas Gleixner (1): tick/common: Align tick period during sched_timer setup kernel/time/tick-common.c | 13 +------------ kernel/time/tick-sched.c | 13 ++++++++++++- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 65b8658da829..e9138cd7a0f5 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -218,19 +218,8 @@ static void tick_setup_device(struct tick_device *td, * this cpu: */ if (tick_do_timer_cpu == TICK_DO_TIMER_BOOT) { - ktime_t next_p; - u32 rem; - tick_do_timer_cpu = cpu; - - next_p = ktime_get(); - div_u64_rem(next_p, TICK_NSEC, &rem); - if (rem) { - next_p -= rem; - next_p += TICK_NSEC; - } - - tick_next_period = next_p; + tick_next_period = ktime_get(); #ifdef CONFIG_NO_HZ_FULL /* * The boot CPU may be nohz_full, in which case set diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 52254679ec48..42c0be3080bd 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -161,8 +161,19 @@ static ktime_t tick_init_jiffy_update(void) raw_spin_lock(&jiffies_lock); write_seqcount_begin(&jiffies_seq); /* Did we start the jiffies update yet ? */ - if (last_jiffies_update == 0) + if (last_jiffies_update == 0) { + u32 rem; + + /* + * Ensure that the tick is aligned to a multiple of + * TICK_NSEC. + */ + div_u64_rem(tick_next_period, TICK_NSEC, &rem); + if (rem) + tick_next_period += TICK_NSEC - rem; + last_jiffies_update = tick_next_period; + } period = last_jiffies_update; write_seqcount_end(&jiffies_seq); raw_spin_unlock(&jiffies_lock);