From nobody Mon Feb 9 13:30:00 2026 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E181215197 for ; Fri, 20 Dec 2024 13:44:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.188.123 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734702282; cv=none; b=WoNxKJB1bUl0u0YPtnxAKSjDFDQP8EGUM3PDpkNtEQ0XU4qJiuYrT68a45EBscBKVaLcYgm6QtrQUM/FLQ1lUiO0DLyxk35IFNd+Z7+lpWl0s7/1DoMGUfkRu7pVnSgf4IXQeZQbw0tgaqf8n6lbBuHpMygzR0FLOvmqLQAvvP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734702282; c=relaxed/simple; bh=lJupxJRNd2yFe+M8cdGyEtntnMDKVxQjZBgUlfKw2BU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QKst0J3of1CHm8cLZ7Bg4MG8WHFPYuwqapQnJ4cpqNSklDoSlQJtBEK1+jxpBQkZtPCXyfjIi27uu+rTxvOI7eV+rJOS2ZVKMRx4d0Wb7BNZKGhI3xDmnCDI9d2pC0LnyOfhSvpv3QJYNN2azCG/dE7LqpCg33/wJQ9uVCqN8DE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=canonical.com; spf=pass smtp.mailfrom=canonical.com; dkim=pass (2048-bit key) header.d=canonical.com header.i=@canonical.com header.b=pyUQnPMM; arc=none smtp.client-ip=185.125.188.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=canonical.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=canonical.com header.i=@canonical.com header.b="pyUQnPMM" Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 4BE924072F for ; Fri, 20 Dec 2024 13:44:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1734702276; bh=N3ITt3OP3QqbaXP+GCfe8exNsHDPHRwpHPUpkLGXg58=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=pyUQnPMMZbJqjBjmrkbotE43xKG29RiFP3uPjWh4O7GLgxz4ChA8UZL/Tis63gngR KIYi/OISPgh5QiBU3BW4yUQSvcQtQUcLVEHIAPP3RL2N2GBXMGDfGr7Sr10nPGRkPi 2QiBUvn2cKEt0hsqrgjT0PK4qyngUuCjr/IcD1sJvpIcsnqFVa05+FDwJFHVVgwrjg I0jm6oVkV7h+FwVkUBuwzjQFRrA15oRX2MlNVZ0VENoh7MPxoEfgV5zDqvupUHeARA RXLnzBapxvTfXMPZSGiAyEIfUCMiozVGoqIywMfUSrSOMdktDIgQD83GJLa+Y/5+u3 H3ndmF4YasKIQ== Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-725f4b412ecso1781522b3a.0 for ; Fri, 20 Dec 2024 05:44:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734702273; x=1735307073; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N3ITt3OP3QqbaXP+GCfe8exNsHDPHRwpHPUpkLGXg58=; b=YLIsEd+gdlcUflzIVq/2ebrhQs4OsDCL+DcMZ8TvBXuhxty802JDMlXhAU2JuKfWaD 1X1aruN8/dII4hui6HlW3QKRAZh8FRr8sEY7+50Xr2MW9lXoInO+ya525ceW65wZF9XA Eamk5obNwyVKMtesEATp4bxICZ/r+tjCK4JYfJd/LnC4YUS/8fTBKQPXu7l+4yQWCrep v0shLHz5ezzNJFWg3HepobSg4KzsZXwY9CexjDN8Xk6gBBlTWa5j31Y91hcw8GTvBPzi OB78PkTznCEf2dfFYqnNaVPPe0302pT//LdD9W9TF4rY78EHlaKTH3xQ5s0yv9PeNSy3 BWbw== X-Gm-Message-State: AOJu0Yy5LFjtngs+2BfYmVfqthrLcBC+aJhFHFZXJCh4tQ47ZKeP0JkF Q2IliGmbvao6EcS7qD3Q7pd+avk2RYQPQSIDZnXtk0O3hP+2mwCyTXpUhAXyRoZq/uAL/hk+gM+ 50oV7B2yTGPWOgbF5Stnw/CPlXPwYwXGJj+W4V5Repso1QVBxFcR8QVPaZjoV/VSz1lRcRJfiw4 iNGWMhP300ww== X-Gm-Gg: ASbGnctu0EgFwNFh/iE65yD+E0zmoTjlmu9Rxts1PRwPpj3VempjA9TM1pZBLaDf7gq lV/swEz3qgB5nisLlx2JPlt+lgC0g9yccj0J28PdwXUdOu1qPTID4tD9HFBxhReljUSGb7dwH1Z VFKyAqMlaTxNzh7WSnK63DsVD06tF8srP4UJwiQ1Wi+fhxP6OWh3x6KfAWD4uCMDeEOmqC4p2fR u5H+qainRXAPvxp3ydi/H5Ioqy7dl9x/qX6b4xdV/E/lWxY6iQdqMl23A== X-Received: by 2002:a05:6a20:1582:b0:1e0:d5f3:f3ed with SMTP id adf61e73a8af0-1e5e048ab3bmr5312580637.19.1734702273690; Fri, 20 Dec 2024 05:44:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IFm/8vuT55npoAdLfMIG55PpoJheUglq+vi2sJP69Rx8B5R+4k38qMC2TqWFPfE/neDWR+pIg== X-Received: by 2002:a05:6a20:1582:b0:1e0:d5f3:f3ed with SMTP id adf61e73a8af0-1e5e048ab3bmr5312553637.19.1734702273430; Fri, 20 Dec 2024 05:44:33 -0800 (PST) Received: from z790sl.. ([240f:74:7be:1:3abc:18f3:dfe7:d8c3]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad8157e2sm3216874b3a.26.2024.12.20.05.44.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2024 05:44:33 -0800 (PST) From: Koichiro Den To: linux-kernel@vger.kernel.org Cc: anna-maria@linutronix.de, frederic@kernel.org, tglx@linutronix.de, peterz@infradead.org Subject: [PATCH] hrtimer: reset .hres_active and .online at appropriate points Date: Fri, 20 Dec 2024 22:44:21 +0900 Message-ID: <20241220134421.3809834-1-koichiro.den@canonical.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a cpu hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE. Since hrtimers_prepare_cpu() does not run, .hres_active remains set to 1 throughout. However, during the cpuhotplug down, the tick and clockevents are shut down at CPUHP_AP_TICK_DYING. On the return to the online state, for instance CFS incorrectly assumes that hrtick is already active, and the chance of clockevent device to transition to oneshot mode is also lost forever for the cpu, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once. This round-trip reveals another issue; .online is not reset to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer(). Reset these fields at the appropriate points. Ideally, .hres_active would be reset in tick_cpu_dying() as underlying clockevent is shut down there. However, since these operations occur in the atomic AP section with interrupts disabled in any case, this patch resets .hres_active to 0 in hrtimers_cpu_dying() for simplicity. Signed-off-by: Koichiro Den --- include/linux/hrtimer.h | 1 + kernel/cpu.c | 2 +- kernel/time/hrtimer.c | 9 +++++++++ 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h index 7ef5f7ef31a9..a5fdd305cabd 100644 --- a/include/linux/hrtimer.h +++ b/include/linux/hrtimer.h @@ -387,6 +387,7 @@ extern void sysrq_timer_list_show(void); =20 int hrtimers_prepare_cpu(unsigned int cpu); #ifdef CONFIG_HOTPLUG_CPU +int hrtimers_cpu_starting(unsigned int cpu); int hrtimers_cpu_dying(unsigned int cpu); #else #define hrtimers_cpu_dying NULL diff --git a/kernel/cpu.c b/kernel/cpu.c index 85fd7ac4561e..34f1a09349fc 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -2180,7 +2180,7 @@ static struct cpuhp_step cpuhp_hp_states[] =3D { }, [CPUHP_AP_HRTIMERS_DYING] =3D { .name =3D "hrtimers:dying", - .startup.single =3D NULL, + .startup.single =3D hrtimers_cpu_starting, .teardown.single =3D hrtimers_cpu_dying, }, [CPUHP_AP_TICK_DYING] =3D { diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 80fe3749d2db..98f23c9341f5 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2246,6 +2246,14 @@ static void migrate_hrtimer_list(struct hrtimer_cloc= k_base *old_base, } } =20 +int hrtimers_cpu_starting(unsigned int cpu) +{ + struct hrtimer_cpu_base *cpu_base =3D &per_cpu(hrtimer_bases, cpu); + + cpu_base->online =3D 1; + return 0; +} + int hrtimers_cpu_dying(unsigned int dying_cpu) { int i, ncpu =3D cpumask_any_and(cpu_active_mask, housekeeping_cpumask(HK_= TYPE_TIMER)); @@ -2275,6 +2283,7 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); =20 raw_spin_unlock(&new_base->lock); + old_base->hres_active =3D 0; old_base->online =3D 0; raw_spin_unlock(&old_base->lock); =20 --=20 2.43.0