Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2124426ioo; Mon, 23 May 2022 10:35:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9DT04ODngcH6HnM2FpgPg48/rjkKXGu7Mq+jhaehsfUM8Ynb+OnqLB4poEiveAOkTtOkB X-Received: by 2002:a05:6a00:2402:b0:4e1:3df2:5373 with SMTP id z2-20020a056a00240200b004e13df25373mr24574688pfh.40.1653327320737; Mon, 23 May 2022 10:35:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653327320; cv=none; d=google.com; s=arc-20160816; b=Z9/kjiGghUBbzfORbGCX8uZklWxyUNxgPc3tGsqNR8cfnB9cKm12BuMQLXMaos+2u0 v2FpYgG72Adv7cnKnulnVBDvaiRs9c6gLz9/ocxb+32sGfOiDkjPLT3jaRGAmfQyF+h5 azgTNYctP743w138crF2TKGilE6KqGMDKqzSXO/aem+3se54s/fDp9KhgzXUu9Jc9Gy0 etrs9/eis2dTeR5ssl2wnucxHk0TLsbSZn+GTOq35FKzFpO+skfTGyL//G8fTBDBvh89 S+aW3+ZSyabM0ItCUSVaKDXBCLOK4AzPURbnR8shTzZPZfISIzBxsAjfcZfoG2gi3hLU l23w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=TUg3EymGqDobAIljlTFZIXDtDgATOC/jsXOiofdEjtI=; b=LnlIzEfdHIVlh29P8MfFjpdNl6VC01Kb5nB2SX0Dyx00alU1uACdv5GQNPZmKDzIp2 RXNvLWvkHgIdu9dR0SjAqMb730gao4qNmvxOYUcBT2UkEAWJdmMcGeSIqCCrhifYIHEr 70o/A6CkOZOPNAzQx35pvDWivCfn6SeVCNZBh8Io0SsuT0HJgYCSdaIrqBILxRo6zuEx BWXA/Vtl8a8eMKjDG1BYAXppuJKDllhMx3xmmwBxSVHNwFnrPm6bGlIlDxk/xnmFOxxH sczh1UvCJS1VAsE7AUhOcGoGIQp6YgazLPN8odWaCwSeYuyMeB26HG5hdtjIErjmEiTd AdGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=isKkstYp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q22-20020a63cc56000000b003db37767241si11215945pgi.281.2022.05.23.10.35.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 10:35:20 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=isKkstYp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BC6D69D4E4; Mon, 23 May 2022 10:34:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240989AbiEWRck (ORCPT + 99 others); Mon, 23 May 2022 13:32:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240787AbiEWRVi (ORCPT ); Mon, 23 May 2022 13:21:38 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4595B737B4; Mon, 23 May 2022 10:18:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B850CB81229; Mon, 23 May 2022 17:18:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2030FC385A9; Mon, 23 May 2022 17:18:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653326284; bh=o4q0gVs0gfviaTGGB5AnUBByDUtGawb79C5sVvmKWRI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=isKkstYpAfdk/uXf64Qx1BLKNRhA1AX3lCm4UvE47jkoabd6MrRnZwkxT7/XjaFie gJkcOcoT8Cz82POgHJWMID8Op1k6T8BXybImLeukWGlE41Pa8yTCfFloO3YVNrwxNz pLUyhVrRwS/XLyAjwcg1SpkZXgBDx1D2SwSPDHbM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andre Przywara , Jernej Skrabec , Alexandre Belloni , Sasha Levin Subject: [PATCH 5.15 026/132] rtc: sun6i: Fix time overflow handling Date: Mon, 23 May 2022 19:03:55 +0200 Message-Id: <20220523165827.845000426@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220523165823.492309987@linuxfoundation.org> References: <20220523165823.492309987@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andre Przywara [ Upstream commit 9f6cd82eca7e91a0d0311242a87c6aa3c2737968 ] Using "unsigned long" for UNIX timestamps is never a good idea, and comparing the value of such a variable against U32_MAX does not do anything useful on 32-bit systems. Use the proper time64_t type when dealing with timestamps, and avoid cutting down the time range unnecessarily. This also fixes the flawed check for the alarm time being too far into the future. The check for this condition is actually somewhat theoretical, as the RTC counts till 2033 only anyways, and 2^32 seconds from now is not before the year 2157 - at which point I hope nobody will be using this hardware anymore. Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220211122643.1343315-4-andre.przywara@arm.com Signed-off-by: Sasha Levin --- drivers/rtc/rtc-sun6i.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c index adec1b14a8de..c551ebf0ac00 100644 --- a/drivers/rtc/rtc-sun6i.c +++ b/drivers/rtc/rtc-sun6i.c @@ -138,7 +138,7 @@ struct sun6i_rtc_dev { const struct sun6i_rtc_clk_data *data; void __iomem *base; int irq; - unsigned long alarm; + time64_t alarm; struct clk_hw hw; struct clk_hw *int_osc; @@ -510,10 +510,8 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm) struct sun6i_rtc_dev *chip = dev_get_drvdata(dev); struct rtc_time *alrm_tm = &wkalrm->time; struct rtc_time tm_now; - unsigned long time_now = 0; - unsigned long time_set = 0; - unsigned long time_gap = 0; - int ret = 0; + time64_t time_now, time_set; + int ret; ret = sun6i_rtc_gettime(dev, &tm_now); if (ret < 0) { @@ -528,9 +526,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm) return -EINVAL; } - time_gap = time_set - time_now; - - if (time_gap > U32_MAX) { + if ((time_set - time_now) > U32_MAX) { dev_err(dev, "Date too far in the future\n"); return -EINVAL; } @@ -539,7 +535,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm) writel(0, chip->base + SUN6I_ALRM_COUNTER); usleep_range(100, 300); - writel(time_gap, chip->base + SUN6I_ALRM_COUNTER); + writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER); chip->alarm = time_set; sun6i_rtc_setaie(wkalrm->enabled, chip); -- 2.35.1