Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2119882ioo; Mon, 23 May 2022 10:29:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJePfJCmyH0xbO1QD66dOM/sqtlNNJG3r/lDtJQ83YpAbeesJ/v6f5PA0G6Y2vFZcRUmOd X-Received: by 2002:a17:90a:ab86:b0:1df:73d4:6d7 with SMTP id n6-20020a17090aab8600b001df73d406d7mr101265pjq.132.1653326960766; Mon, 23 May 2022 10:29:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653326960; cv=none; d=google.com; s=arc-20160816; b=Hxy6fc4RrScR//YI4X6es71fzM2hM00H3ichuhL9RuQ+2td2qtgpKVoVVIs9X9uVTN td/0N7I1Pa2Kd5UKulOWGkTK3vHnMVHAWNYRUCzWWvmmjT4VeRuB8ZnDpjaBE3VKhmwV Tp7CcO+oDpo5dojX3fmZDbzS9yLh7eSgO4BFJd/HEY1rNz1oZE3tUe1n6p3V+PBbUAdM nU77YRVFtKW16fE4dFNIt7fKv25VH/i2Lq+0q8KslkvRWyo6fHXVDo3RGU5G1/dUjkCm 0JRtfs5ZiyXXyqQglE69vvTOtPApaMps2WP86WzixjQbb42L45QosMuaqjyb0bySOaPW Wpqg== 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=RgmuYUdVNTU6No74SCeqrKhxxDHNPXMOcv1MKh8hh7s=; b=c4F7ZGGJ7UYySR/SDHc5oNdaLfzZzrPcjnGtMkLOcmPTzyyXcRS0MTAEFpzILHHM+p sWpm/npp6Dr59WhqyDLu5UBFoizWHiFtPcq76d5vD9PcPUCL3DRScj/TeOD/LqLD0ypf tfuVJzvFPNPw3zou0hjZUg25rEx5/T0P0zPVzUoAy4QzhDEa5UqkPITxOF02xBr5OYAt wyp0ydffsrMus88+f6DpNWEiXkcqEyB4S3h/UoFbVX181EeovA15UeFX5eiYNj8sVPdB kuw1OhmAWkB3X4bN4LE2HUPRisMqPr+r3pI2Yg6D3TkXyORW5z9rLfO/t/0BUU8lBUTZ ToeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="si6/M4Cc"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id n15-20020a6546cf000000b003f5fa8c55e9si11923645pgr.9.2022.05.23.10.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 10:29:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="si6/M4Cc"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 344FF81494; Mon, 23 May 2022 10:29:04 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240734AbiEWRZz (ORCPT + 99 others); Mon, 23 May 2022 13:25:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240573AbiEWRQa (ORCPT ); Mon, 23 May 2022 13:16:30 -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 C716E72E04; Mon, 23 May 2022 10:15:56 -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 10D88B81218; Mon, 23 May 2022 17:15:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EF8BC34115; Mon, 23 May 2022 17:15:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653326114; bh=rmjlrZ3jRBAG1u+k/uE6IQjsP8+3rNHHrRvB1TBMCIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=si6/M4Cc2v4sWOlD404PIxGGnXIJGvj2bZKPxHBtZOtEYq2Ver8r8yULRDwXm+DAd 22GCuHtTTJPy0flfVCpGFmnrz6+wC36cociIH0BNb08uo2HefoLsG9ZzjhpDmgTkQB 2Vhmikn0oive4ilxBq1bGsjNru8gFAsIyUl63veQ= 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.10 15/97] rtc: sun6i: Fix time overflow handling Date: Mon, 23 May 2022 19:05:19 +0200 Message-Id: <20220523165814.759854261@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220523165812.244140613@linuxfoundation.org> References: <20220523165812.244140613@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 f2818cdd11d8..52b36b7c6129 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