From nobody Sun Feb 8 02:41:48 2026 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 D889318E1F for ; Fri, 30 Jan 2026 19:49:28 +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=1769802568; cv=none; b=tyR4/EtcsLtr5vU1gwYo36VMnrSxWwmdXHBjhuuhOYAm3p/TXcRKb3d6P16p1HD7hPYZk8VIwFFdQeiVNCYlbuucHqaEI8AW0Uln6YmtTnuOlU6d2IDtBGCeObvriRyZhtuo+bpsaiGQenyoPCGN52l6JUQfwZ46ER23zXY/kIo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769802568; c=relaxed/simple; bh=OPaOroOgSz+u6kNgEkji5B1xynGeoHfVeNWc1JZeBP8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=duHere1u13JAGaZx5T5cdziOwsOc2GVOCRhk29qroaCAlPvyeXd5tsw6BQiPHbB1hugEFRxBxlWYeSkU65Hra5mS0TDYFU4cKuturcKOzgyVn5RrBe9m/ndS5XOAWjObDJIwvwKSPVh5O66gaoTw85BYdL6BeIxapNUK3Ed2AHs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qsGYhpOQ; 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="qsGYhpOQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C345C4CEF7; Fri, 30 Jan 2026 19:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769802568; bh=OPaOroOgSz+u6kNgEkji5B1xynGeoHfVeNWc1JZeBP8=; h=From:Date:Subject:To:Cc:From; b=qsGYhpOQQp4EqhFXcpmAin9ygsENSXPIfmxr91vsvPdLpSwFoDbJHcc8xpHTYFk4u V/ndNXn8Z+84FrkEI/j+yhm23NGH688J2ejc+MenLWtNf57uGQqvQrMPWqIm3cyITW PT0w1/sexNxebFuKbVh+ozk01PY1wpeOdHwhn8XzMUmAwASE21Tb+nRH+DDn22tGn9 CXpBp0BoAw11oQC58/EGdgyE0117geTKs1iYzsy0RHuqiX8uBP0ojNwd974keSjE0n 5RFDMGTDoU2gqm+U4X4yWj7AwE1/aqR9JNo9ftEy72UvjgNBs2LWf74BypPiCmeKf1 LJ61Lomyu3G5w== From: Mark Brown Date: Fri, 30 Jan 2026 19:48:35 +0000 Subject: [PATCH] time/kunit: Handle testing negative years 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 Message-Id: <20260130-kunit-fix-leap-year-v1-1-92ddf55dffd7@kernel.org> X-B4-Tracking: v=1; b=H4sIABILfWkC/yXMQQ7CIBCF4as0s3YSKAajV2lcDDDq2IY20DYaw t1FXX7Je3+BzEk4w6UrkHiXLHNs0IcO/IPinVFCM/Sqt0obheMWZcWbvHBiWvDNlNCe3Nkcg9F kCNpzSdwGv+pw/Ttv7sl+/aag1g/sOKjldwAAAA== X-Change-ID: 20260130-kunit-fix-leap-year-67b934d31a3a To: John Stultz , Thomas Gleixner , Stephen Boyd , Jinjie Ruan Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Mark Brown X-Mailer: b4 0.15-dev-47773 X-Developer-Signature: v=1; a=openpgp-sha256; l=2143; i=broonie@kernel.org; h=from:subject:message-id; bh=OPaOroOgSz+u6kNgEkji5B1xynGeoHfVeNWc1JZeBP8=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBpfQtGawl4k8jlObhuWX1BGuq//atB/5KhfK1R7 PLfYB/N/h6JATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCaX0LRgAKCRAk1otyXVSH 0KbHB/wNlK4r0hLPbO6lJyeOgYwDnk+pbjzDNN83OZLi0mv5yz7SHCgl78g2l2yyqvMCqIdCJ8W oUttkRsYBv0R2qUStc6KwG6ebMTWENdORGBXaido7CxUBYMJwtpRwEcuW8XiOl+/wV7Jk4FfWJY 3XrTyoVv0jx2KQiXChe6Rmwwll9HZpmk9/kC9PryVRBFG8nIWX7/9IJbXfubf77FWcqlIV9iQbB plVYfAJXOJOe+CUcLEKZUl/Hflwdyjr4ZMhTy9fvk6pT+W6kumNLaJN+ug3hz314bXfMcfZUeBP npoYVks9mT0qQL2l+plsTMY2CWZSAwAYcdWMKp2DIkpvJ+4z X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB In 3d431a106947a ("time/kunit: Use is_leap_year() helper") we replaced the local is_leap() function with is_leap_year() from the RTC code. Unfortunately the two aren't exactly equivalent, we move from using a signed value for the year to an unsigned one. Since the KUnit tests cover a 16000 year range around the epoch they use year values that are very comfortably negative and hence get mishandled when passed into is_leap_year(): [14:26:27] # time64_to_tm_test_date_range: ASSERTION FAILED at kernel/t= ime/time_test.c:73 [14:26:27] Expected month - 1 =3D=3D result.tm_mon, but [14:26:27] month - 1 =3D=3D 2 (0x2) [14:26:27] result.tm_mon =3D=3D 1 (0x1) [14:26:27] -77996/03/01 (59) : -29206923 [14:26:27] # time64_to_tm_test_date_range.speed: slow [14:26:27] [FAILED] time64_to_tm_test_date_range Revert to using our local implementation, adding a comment warning of the issue while we're at it. Fixes: 3d431a106947a ("time/kunit: Use is_leap_year() helper") Signed-off-by: Mark Brown --- kernel/time/time_test.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/kernel/time/time_test.c b/kernel/time/time_test.c index 7c2fb5f775eb..3c60fad07b6f 100644 --- a/kernel/time/time_test.c +++ b/kernel/time/time_test.c @@ -2,7 +2,15 @@ =20 #include #include -#include + +/* + * Traditional implementation of leap year evaluation, note that long + * is a signed type and the tests do cover negative year values. + */ +static bool is_leap(long year) +{ + return year % 4 =3D=3D 0 && (year % 100 !=3D 0 || year % 400 =3D=3D 0); +} =20 /* * Gets the last day of a month. @@ -10,7 +18,7 @@ static int last_day_of_month(long year, int month) { if (month =3D=3D 2) - return 28 + is_leap_year(year); + return 28 + is_leap(year); if (month =3D=3D 4 || month =3D=3D 6 || month =3D=3D 9 || month =3D=3D 11) return 30; return 31; --- base-commit: 3d431a106947a4a18ff5d3ba270a25df6a136e2f change-id: 20260130-kunit-fix-leap-year-67b934d31a3a Best regards, -- =20 Mark Brown