From nobody Wed Oct 15 22:31:22 2025 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 D0F43219534; Sun, 24 Mar 2024 23:35:47 +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=1711323347; cv=none; b=g4daSh9PEqkjwlFGOQFV071ZwzUMPobkiPvqQTTvjwUEIhWENcZaTep+rdBbL5fXBZdK3hHq3t2ktZauZ+FkK63NbjeJL/U67gFJGZ9hIj8bUrmjlMLknl48jWKxqno9dyioyhJmu8W0QMcGP/+2M/BmchGBhdXDd3LNffeqWzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711323347; c=relaxed/simple; bh=Ys1n7KO/doY4y5NcqibK4xwVEo5LrW7J0qV0kpbP6Ts=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F601oaDswYJ66YYJ5KhL6yePG6Hxs7ZFeccd2sDkV+gSW/d3U3PQxUPZDxqkolCKTRGQJB4nWIXYFowXhIRh0M4GM+sXgrwDEBZxpWNs059Z69aXbeYWYaa0GkuWUueXlQtGetIqPDj5RJREsDad8J8tBbyeadnOFYe+dNvlZ8g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ql0tLyGU; 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="ql0tLyGU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC391C433C7; Sun, 24 Mar 2024 23:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711323347; bh=Ys1n7KO/doY4y5NcqibK4xwVEo5LrW7J0qV0kpbP6Ts=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ql0tLyGUOsE5mmja6c+Wpl/kmH2ORNFqCiGhKIbSVAdL4y8L581CLC/YCjKVuawD9 iSrxndixtJ+VIkz7yUyvOuXpCqJZrhFRyUejigLRRpkM5I8lfu++YoCHW4cJMtxu5n ZRcmM81bZqn1qhqQuQtWZCZPn3g72dSvFJVMGhHnyzhWR3R7SkD78dbUDtptNzuNmn KvpLNU8+VzXme0xX7ka9v0+LRFP8lypfTPZ03aeO3SBs2b/bFV3hxDi4aMZVCkxS0x cckawjNfqRh6DvCnkqsyFm9IyP3a+/0woDQDAiOPA5UQK/QMUjYjRdPRYN9Il8t65a YepGTBNbEg0eQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Hilber , Thomas Gleixner , Sasha Levin Subject: [PATCH 5.15 047/317] timekeeping: Fix cross-timestamp interpolation corner case decision Date: Sun, 24 Mar 2024 19:30:27 -0400 Message-ID: <20240324233458.1352854-48-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324233458.1352854-1-sashal@kernel.org> References: <20240324233458.1352854-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Hilber [ Upstream commit 87a41130881995f82f7adbafbfeddaebfb35f0ef ] The cycle_between() helper checks if parameter test is in the open interval (before, after). Colloquially speaking, this also applies to the counter wrap-around special case before > after. get_device_system_crosststamp() currently uses cycle_between() at the first call site to decide whether to interpolate for older counter readings. get_device_system_crosststamp() has the following problem with cycle_between() testing against an open interval: Assume that, by chance, cycles =3D=3D tk->tkr_mono.cycle_last (in the following, "cycle_last" for brevity). Then, cycle_between() at the first call site, with effective argument values cycle_between(cycle_last, cycles, now), returns false, enabling interpolation. During interpolation, get_device_system_crosststamp() will then call cycle_between() at the second call site (if a history_begin was supplied). The effective argument values are cycle_between(history_begin->cycles, cycles, cycles), since system_counterval.cycles =3D=3D interval_start =3D=3D cycles, per the assum= ption. Due to the test against the open interval, cycle_between() returns false again. This causes get_device_system_crosststamp() to return -EINVAL. This failure should be avoided, since get_device_system_crosststamp() works both when cycles follows cycle_last (no interpolation), and when cycles precedes cycle_last (interpolation). For the case cycles =3D=3D cycle_last, interpolation is actually unneeded. Fix this by changing cycle_between() into timestamp_in_interval(), which now checks against the closed interval, rather than the open interval. This changes the get_device_system_crosststamp() behavior for three corner cases: 1. Bypass interpolation in the case cycles =3D=3D tk->tkr_mono.cycle_last, fixing the problem described above. 2. At the first timestamp_in_interval() call site, cycles =3D=3D now no lon= ger causes failure. 3. At the second timestamp_in_interval() call site, history_begin->cycles =3D=3D system_counterval.cycles no longer causes failure. adjust_historical_crosststamp() also works for this corner case, where partial_history_cycles =3D=3D total_history_cycles. These behavioral changes should not cause any problems. Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface suppor= ting slower devices") Signed-off-by: Peter Hilber Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20231218073849.35294-3-peter.hilber@opensyn= ergy.com Signed-off-by: Sasha Levin --- kernel/time/timekeeping.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 985aa75eedb24..d21280b3b2ea7 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1163,13 +1163,15 @@ static int adjust_historical_crosststamp(struct sys= tem_time_snapshot *history, } =20 /* - * cycle_between - true if test occurs chronologically between before and = after + * timestamp_in_interval - true if ts is chronologically in [start, end] + * + * True if ts occurs chronologically at or after start, and before or at e= nd. */ -static bool cycle_between(u64 before, u64 test, u64 after) +static bool timestamp_in_interval(u64 start, u64 end, u64 ts) { - if (test > before && test < after) + if (ts >=3D start && ts <=3D end) return true; - if (before > after && (test > before || test < after)) + if (start > end && (ts >=3D start || ts <=3D end)) return true; return false; } @@ -1229,7 +1231,7 @@ int get_device_system_crosststamp(int (*get_time_fn) */ now =3D tk_clock_read(&tk->tkr_mono); interval_start =3D tk->tkr_mono.cycle_last; - if (!cycle_between(interval_start, cycles, now)) { + if (!timestamp_in_interval(interval_start, now, cycles)) { clock_was_set_seq =3D tk->clock_was_set_seq; cs_was_changed_seq =3D tk->cs_was_changed_seq; cycles =3D interval_start; @@ -1260,13 +1262,13 @@ int get_device_system_crosststamp(int (*get_time_fn) bool discontinuity; =20 /* - * Check that the counter value occurs after the provided + * Check that the counter value is not before the provided * history reference and that the history doesn't cross a * clocksource change */ if (!history_begin || - !cycle_between(history_begin->cycles, - system_counterval.cycles, cycles) || + !timestamp_in_interval(history_begin->cycles, + cycles, system_counterval.cycles) || history_begin->cs_was_changed_seq !=3D cs_was_changed_seq) return -EINVAL; partial_history_cycles =3D cycles - system_counterval.cycles; --=20 2.43.0