Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3669746lfo; Mon, 23 May 2022 10:55:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBwnIZravdil8ObHUYqNkkt1PXxGIhCRet/BC95PfkIS8yyOkaDwYpGTS2tvo2naqPY4fV X-Received: by 2002:a05:6a00:1901:b0:518:916e:4a85 with SMTP id y1-20020a056a00190100b00518916e4a85mr9742690pfi.65.1653328505210; Mon, 23 May 2022 10:55:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653328505; cv=none; d=google.com; s=arc-20160816; b=MqgDW7zhJ9Bx41AtqK2yMJ28nEDxjA13Pzcob5raAD6xf+qKQ+yemAZ7HiDOop6zbS 8CmKm2Tm/qj/YyVWvOk8OBzekhohXC5CVebynmfDsxvLIHbS8k0inREjN2/K1Z3E0c1a ESmgSkHyjPe/6NiydEqvoPcuJ+NOzVzvwfQHx+RWt5ADFStl7AgXWVVSuSMaaVrV3wrW aYXLl0OEBHYGEpesu3ndlUZ9eS/Lcg6S4DzJxFrEaKxoIPjWfY+ou7aqf8IHiwU6w8Y1 xALG0vEcuehKIRFQ/9bGEln6RAn022cdwa1YG0vnamcviGmzmpbHgKgXLCZj5vLBBsoQ OCMA== 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=JV+eDUBUf6bPzSfQorfz3kSynMqjcsGn+UD2eesQu+s=; b=BJ3C9g0edEcvDsZSWNlxZcfvCCqOJBBNeAFBfc17VccoIPBv1As58GmCPzaTKBOJiQ 1fAFtT5sxKD3fwQn7A41ki1PCSDY10gjKpPhr+yPMitsy3F0q5TmfCKczb1w75IZAf5Y hVpl1g1NZeVZ9YhyBogQmL89oGb+HkHov053u+fuhUU8XbMjzIGbHiNoobck7hfiYeFm mZts+Kly7iQUIpvE+TYLUI2AW88Y9C2kPJBILTEzUANKe/lW2ypeWQpbhwb+jO+6biHN fFUHs6XzQzBuoe7+/nrJM87dLLpXtR8Cacz2dzzGR0iOqPXr0XLhgzCr+8f22Rrn6Mbr NGkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1ujcakOx; 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 m10-20020a170902db0a00b0015d0d05846dsi12317836plx.430.2022.05.23.10.55.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 10:55:05 -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=1ujcakOx; 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 7243D1116E9; Mon, 23 May 2022 10:53:51 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243171AbiEWRvG (ORCPT + 99 others); Mon, 23 May 2022 13:51:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240870AbiEWR3L (ORCPT ); Mon, 23 May 2022 13:29:11 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB83637010; Mon, 23 May 2022 10:26:25 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 6CB876090C; Mon, 23 May 2022 17:24:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70A4BC34115; Mon, 23 May 2022 17:24:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653326685; bh=adLbLelwA0eTEMAxwIejJevJ/N5XHRVQmd9kn8IfuU0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1ujcakOxzjaVjPu+f7gWwKCJDeJ8h0DFuC8FRmEi8sfykTzJ0bbgnK8YofLwPlRcb feQyK8hiWjjjVkWE8Jq4gQht7qum4/vmmmjJOrHhumfcl4hyvEuVbY+VwnV7KNdKEz eDlbl226BgmQ5ykCQHMCBIaAjrbqWIN2ZXd4wBwY= 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.17 027/158] rtc: sun6i: Fix time overflow handling Date: Mon, 23 May 2022 19:03:04 +0200 Message-Id: <20220523165835.012042591@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220523165830.581652127@linuxfoundation.org> References: <20220523165830.581652127@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 711832c758ae..bcc0c2ce4b4e 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