From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1AD05ECAAD3 for ; Thu, 1 Sep 2022 12:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QsSKHcIpYcQgZuBe3ggUZX3wp/T47RTWwCGJqQ+4nF4=; b=i8s4a1nI9QwZ5F A/ruX1Qa9rJxSeFAGKXLLln2ffhnxnhqAGYluc9ryI3Bq3uRlLDqtTDeBGG66BNEh61BkPffLMg1d 822f1CWojxnIPNYorYqA6HEQTv5ku5JYT0Z6KpsEAbofzwUlR++N5lz75eZLm7xPiNs2zsMsmzM/3 KqSJOwh+rVqQBdEAMxqcHCkHfv6iOmi8EAQyHt6F0kysCVYqtVWJzxIxm77TAFpCbB0ad2Bu7GZIA t0Y7p1bp4sPnwMCO9nPLRu8dE2Tmzv1KVWdobfWZFoySeBZRND2jYTd1ErnAH6sftTLwTAzhKJ+9d Zdj5Tp7BT08Q9PKpxfdQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTje4-00BltS-UJ; Thu, 01 Sep 2022 12:50:09 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTjdw-00Blpv-HV for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 12:50:02 +0000 Received: (Authenticated sender: alexandre.belloni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id D2E42C0008; Thu, 1 Sep 2022 12:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1662036595; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9URVkwgrw3/LBC+MRmp/ARWWLqi8d3hXLofy+g2t2qI=; b=U9L1JWtumDEoSzEz8bwR0Sg1udzWW4bC2EFVULhc7oGB4yMClghHtIIzXFjpSA8DOxnuSB OtiXp+oWTglSc2jZwEH4Bf4NQtWv9Ju7y04QV1lH0YqJQCf63S4gvAp/N3NtjwBsIxA6ap VyOQJV+nDQkoFtmb152fxQSiaqU19al2TIvo6ngXBpNy/x2285WdlU21MmvbF4GbS2/LcX wmG8iO6r9XKPCba1PE2aTpagGN1P5dYeSI99n6kt95C9kvULsmBUL5kKCUTZNM5DTS9XPF emlMyfNqz/KbNOJhwGozid4EN/dPsoBNCTloLybHd1EFYFlT4xGhOgSek5Whfw== Date: Thu, 1 Sep 2022 14:49:54 +0200 From: Alexandre Belloni To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org Subject: Re: RTC hctosys disabled for 32-bit systems Message-ID: References: <802ca9c8-4b61-4568-a946-8e6330807eb3@www.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <802ca9c8-4b61-4568-a946-8e6330807eb3@www.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_055000_751792_3281197F X-CRM114-Status: GOOD ( 26.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote: > On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote: > > > > I'm working to fix the y2038 issue for an existing sama5d3-based > > product. This involves updating the kernel and glibc to appropriate > > versions (5.10 and 2.35.1 respectively) and I got things running up to > > a state where, from userspace, both date and hwclock commands have no > > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS > > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver > > fails to initialize the system clock at bootup. > > > > Some digging in rtc/class.c::rtc_hctosys() indicates that > > do_settimeofday64() is deliberately not executed on systems with > > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed > > that the work on 64-bits timestamps was already fully implemented for > > 32-bit systems as well, so my gut feel is that this > > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with > > these checks disabled results in correct time initialization at bootup > > with, at a glance, no adverse effects. Does anybody here know whether > > do_settimeofday64() is robust on 32-bit systems or that the checks > > are still required to prevent further breakage? > > Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time > doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143 > for the problem that originally caused this to be added. > > Removing this check would probably break systemd again for machines > that return a post-y2038 time with systemd built on 32-bit time_t. > > The only reliable fix I can see would be to disable > CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan > for the long run anyway, but I don't know if there has been any > progress in convincing distros to turn it off. > This is still my plan but systemd mandates RTC_HCTOSYS and I couldn't convince Lennart otherwise. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel