From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 15C4938836F for ; Wed, 4 Mar 2026 22:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772665085; cv=none; b=H72yU3snMkK9ABcC8t/EYhz01wkEn2/My0z+b60YQVpMvMtPtd4V+G0UHUNWAmj14F/uFCbqBxY9BH1uw8Cwj5Sv7AY8kEkIbqhphOnHTMkC8NMdadxBMgQ43xavf0bqfX5snBMoXruLYPnE6vcDqyAfWtqlBgy1VtENxFQWNys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772665085; c=relaxed/simple; bh=Cx9PEMt2U//1znZyYX4am1/iuEo9fUgsldpceF9mpdk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PABNVuAM9BPLK7GbcUPEDFCnQLiUdCjXHIQtsfnrmcqPEFb0jzKyl6qtHUqgiHoDg6n7Yeez9JlCQzG/WR83Df1BN2ujWuwJ/Acb9i3VFDDHfbN9UwRm3BpjnQdIGyAroP8zY45v03J44FXg2L2xPAuQ9GqCtggEXyAoLOxbAvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TBHE84g7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TBHE84g7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A6ADC4CEF7; Wed, 4 Mar 2026 22:58:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772665084; bh=Cx9PEMt2U//1znZyYX4am1/iuEo9fUgsldpceF9mpdk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TBHE84g7apGiJ/hxf4+U84Ah+2cE2IbBmWkX5UFONmKEFvpmXnY6JYdEmeWgLGVUb NamG+99A7+NfFgY+t9J6iyXqK55ufY/RnPVofvO9HFmgpOs5IrMZsiPSq9b+avXAUa UAy/PATnM9Ux8XUdYHE3hGi6VCmBxt7O9OO8x3WYukuvhudaPNu/ffJVx6EHHTmgaF S54iiObOUoOfnTx5TVttTpH8CkzkfqOcCJMTA5srLAkJ011jY+HsOm94RTmgkCBRKc dH9Jx0D1G3MHXWcUIS78FpQyJcuTyFprn3OvOOJSN+gKEehoeOiwDfDgdCVlhPH9il OGsMJiulEwU8A== Date: Wed, 4 Mar 2026 15:57:58 -0700 From: Nathan Chancellor To: Thomas Gleixner Cc: LKML , Anna-Maria Behnsen , John Stultz , Stephen Boyd , Daniel Lezcano , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , x86@kernel.org, Peter Zijlstra , Frederic Weisbecker , Eric Dumazet Subject: Re: [patch 20/48] clocksource: Update clocksource::freq_khz on registration Message-ID: <20260304225758.GA3903057@ax162> References: <20260224163022.795809588@kernel.org> <20260224163430.076565985@kernel.org> <20260303012905.GA978396@ax162> <87jyvtyo6o.ffs@tglx> <20260303173809.GA1114907@ax162> <87ecm0zmsf.ffs@tglx> <20260303213027.GA2168957@ax162> <87h5qvsajx.ffs@tglx> <87cy1jsa4m.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87cy1jsa4m.ffs@tglx> On Wed, Mar 04, 2026 at 07:49:29PM +0100, Thomas Gleixner wrote: > Borislav reported a division by zero in the timekeeping code and random > hangs with the new coupled clocksource/clockevent functionality. > > It turned out that the TSC clocksource is not always updating the > freq_khz field of the clocksource on registration. The coupled mode > conversion calculation requires the frequency and as it's not > initialized the resulting factor is zero or a random value. As a > consequence this causes a division by zero or random boot hangs. > > Instead of chasing down all clocksources which fail to update that > member, fill it in at registration time where the caller has to supply > the frequency anyway. Except for special clocksources like jiffies which > never can have coupled mode. > > To make this more robust put a check into the registration function to > validate that the caller supplied a frequency if the coupled mode > feature bit is set. If not, emit a warning and clear the feature bit. > > Fixes: cd38bdb8e696 ("timekeeping: Provide infrastructure for coupled clockevents") > Reported-by: Borislav Petkov > Reported-by: Nathan Chancellor > Signed-off-by: Thomas Gleixner Tested-by: Nathan Chancellor > --- > kernel/time/clocksource.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > --- a/kernel/time/clocksource.c > +++ b/kernel/time/clocksource.c > @@ -1169,6 +1169,9 @@ void __clocksource_update_freq_scale(str > > clocks_calc_mult_shift(&cs->mult, &cs->shift, freq, > NSEC_PER_SEC / scale, sec * scale); > + > + /* Update cs::freq_khz */ > + cs->freq_khz = div_u64((u64)freq * scale, 1000); > } > > /* > @@ -1241,6 +1244,10 @@ int __clocksource_register_scale(struct > > if (WARN_ON_ONCE((unsigned int)cs->id >= CSID_MAX)) > cs->id = CSID_GENERIC; > + > + if (WARN_ON_ONCE(!freq && cs->flags & CLOCK_SOURCE_HAS_COUPLED_CLOCK_EVENT)) > + cs->flags &= ~CLOCK_SOURCE_HAS_COUPLED_CLOCK_EVENT; > + > if (cs->vdso_clock_mode < 0 || > cs->vdso_clock_mode >= VDSO_CLOCKMODE_MAX) { > pr_warn("clocksource %s registered with invalid VDSO mode %d. Disabling VDSO support.\n",