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 8093EECAAD1 for ; Thu, 1 Sep 2022 13:59:13 +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=s/fVZRm/1/VqzCvUZ/dv/q0lAX845xkKnX7NfhAKQNA=; b=SkZjN1lEv+H83E o1eVOFQZ68jgR/XPlcucnV9PTwbmj+Sxq+nOfCIabLpkGuxN/baAS9JNBODJMrE94autIrmoHQI1j XTZS+XslAK+gXyWlezUvfzZZNG19vTlIkO2UCQq/CWuWQe3PVCID066eXh2t+ZI+qdT/e6H4vxmkD k0HuvxqCHEO18GS3KWnG/u5QZ11oRQCAfpjZW0c+4d1Uco8+hKbjnf5Bp2NUG6qeSZpBXJ1LrVN3T VWpeD/8R9wUcj+RZEF7sivIJ6VPZZgKHjqxJbmMkV3PzrZMpzoNisN+FyJp23zpuWRw5QFnpMGfkq f2U8LOO34yhDjRIftAIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTkhp-00CGzj-P3; Thu, 01 Sep 2022 13:58:05 +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 1oTkhm-00CGv7-9N for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 13:58:04 +0000 Received: (Authenticated sender: alexandre.belloni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 19674C000B; Thu, 1 Sep 2022 13:57:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1662040676; 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=EYNAaexhi1AvZtDAtvCNMdAprLLYMYkxdTVHicuD9mA=; b=CZ+jJA/1fRYv7KsAQWKUnNEOsUEFCz9KOR01KVpvFSONZoH/k0guk9gRMlNhHTdOeJm/5g vUHFBYFKWcTs6R4qEaeIJwZ2JoIq5I/yruWuKe6/32H5djKShI7ebYXgzbqK5NzpG5iV5M m6bkmb/eZL7MyU1/hfY4ucbnonlOeEGVvYx9j+9W/eqh4diD9sobDzyXBN1LAJjhht+4lk pIrWFeYcRGDUnX89Q7nTEgcxNbvnHw0Lzci4XF15zjq4Scw7Wab+Gg2ryv9FYXXxWGL9+J XHrt4qvuv4rZn8C3IB6mFB4yMU4AOvNdPoaOKEQ+DLnBft38+tagovI41Q+75Q== Date: Thu, 1 Sep 2022 15:57:55 +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> <8eca48d9-bd10-4857-9e43-a5b20a8db625@www.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8eca48d9-bd10-4857-9e43-a5b20a8db625@www.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_065802_510583_6B33FA0A X-CRM114-Status: GOOD ( 33.09 ) 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 15:12:57+0200, Arnd Bergmann wrote: > On Thu, Sep 1, 2022, at 2:49 PM, Alexandre Belloni wrote: > > On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote: > >> > >> 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. > > Ah, I forgot that systemd actually needs it. So I guess there is > currently no way to use systemd on 32-bit machines that are > meant to survive 2038, regardless of whether systemd and glibc are > built with a 64-bit time_t or not, right? > Well, it doesn't actually need it. It could as well go and read the RTC and decide what to do with the time it gets. The main reason they want it is because the log timestamps are correct earlier when the kernel does it. > Is there perhaps a way to change the logic in a way that > it does not depend on the current time but instead depends > on a property of the RTC device itself, so we make systems > break immediately instead of by surprise in 2038? The safe thing to do is really to not use hctosys and have a systemd unit that reads the RTC from userspace. See https://github.com/systemd/systemd/issues/17737 for the whole discussion. > > As far as I remember, the workaround was only needed for > certain devices that may set the time to something after 2038 > on a depleted battery, but other devices would have a better > failure case, right? > Yes, this is the main cause, anything able to set the system time after 2038 with a 32bit userspace will cause that (and basically I think this is only hctosys). The issue is that many RTCs don't have a default value for the time registers after power failure. This is usually not an issue as there is also a bit allowing to detect whether the time is correct. note that this will also be an issue once we actually reach 2038 with a 32bit userspace. -- 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