From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 0B6F739A074 for ; Sun, 24 May 2026 15:15:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779635712; cv=none; b=PWOHg9SpNv77Q7wJHwQakbNeoOU+nfwCfXdmxqXwKh1cidoIYcnTo5Hp5OY/NElystF6RLeC8Fsox3DQCUWonDyVitlCdmtDf3q1YrP8q26ZUS+5CDlKiOhv42Hss+HRxXEhEybknaeT9MEHa1fHiq3fD15Gwc7soa5EQuBi8XU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779635712; c=relaxed/simple; bh=g15QTyfvAWLrjPwRMyDywXplLr7s99eSxibBLMtBcAQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mFy720qXFbzf23JfFdPb4Vunjm/PCgsiTJODSVrljiT3x4/M6GRxAj7tMe+1g4mrqDkdhqYsoS3kfmQaNFMPdYArnoVGtU9BIWH7zTaMmJHgjR0d7GfgHjTJw4XmOEfVYeikSoboX/JMeZ26TUIO7jnQRXTZYPYC+9s/c+p/xjI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ov9k0dGZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ov9k0dGZ" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 1EDA81F000E9; Sun, 24 May 2026 15:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779635710; bh=EYg48GsMA/itoLBXmQYdym9VOb+5Pl56GD1acK6JO5k=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ov9k0dGZiSsXI2iMdqKoCdOb1cYDy9pabILOc6cMDFkGw0sradxwf7LxkHmqAFq8X MVGUYQaoMi3EL0QqG5IiaZ3xNj/y610zxBRkbapGAGJQamNXv9nquA8vQ5zQSfrvhk tfLo90I+IGn5Hduaz+OHXeO8IEcTdHNVLE0d6YpkWN/gqOrWRJnia7PpU8HKt/w90P zvVYoS1SjHbJclcLRdIuhKW5DzUVi1YusxJxsTGQWSKixgI5jmoKeqWvcQG0vMh3zi P0Tjb3z+/JplLOassEhgfuaBa4/O/rzI5EVrzHQe+G7BuLHVQhoKE2K+VkmAucPqEy OFaI7Xe+7tL7w== From: Thomas Gleixner To: David Woodhouse , Miroslav Lichvar Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock In-Reply-To: <0b1f41d3709b18c375e6f2743547016afe2ab32c.camel@infradead.org> References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> <87o6i8vcni.ffs@tglx> <6c7137748ccea288fdf55e7c2e24817ccc1673ef.camel@infradead.org> <874ijzvpl8.ffs@tglx> <00609fa255442648e11e2b5596a3b80a29edcfc8.camel@infradead.org> <87v7cftqey.ffs@tglx> <0b1f41d3709b18c375e6f2743547016afe2ab32c.camel@infradead.org> Date: Sun, 24 May 2026 17:15:07 +0200 Message-ID: <87jyssu9dw.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=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, May 22 2026 at 17:50, David Woodhouse wrote: > On Fri, 2026-05-22 at 17:28 +0200, Thomas Gleixner wrote: >>=20 >> =C2=A0 git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp= /timekeeping > > In 94dd85a8d0a ("timekeeping: Add system_counterval_t to struct > system_device_crosststamp") my version ditched the system_counterval_t > on the stack and just used the one in xtstamp directly. Which is wrong. I did it the way I did for a very good reason. > The convert_base_to_cs() function probably wants to scv->id=3Dcs->id for > itself anyway; otherwise it's leaving behind an inconsistent > system_counterval_t object which... will lead to exactly the bug my > first version of that had, that I see you avoided :) No. It can't because that would corrupt the object for the retry case, which would then hand back the wrong value. The object _IS_ consistent because the csid in there is related to the PTM value and not to the clocksource. The function updates the @cycles value and leaves everything else untouched. The clock ID for the @cyles value is guaranteed to be the clock ID of the system clocksource, so using this is the right thing to do. Just because it looks tempting or your AI buddy told you so doesn't make it correct. Thanks, tglx