From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C14002BCF8 for ; Sun, 3 Mar 2024 16:17:15 +0100 (CET) Received: (qmail 32586 invoked by uid 550); 3 Mar 2024 15:13:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32545 invoked from network); 3 Mar 2024 15:13:25 -0000 Date: Sun, 3 Mar 2024 10:17:19 -0500 From: Rich Felker To: Thomas Petazzoni Cc: busybox@busybox.net, musl@lists.openwall.com, Waldemar Brodkorb Message-ID: <20240303151717.GD4163@brightrain.aerifal.cx> References: <20240303153611.604aa33b@windsurf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240303153611.604aa33b@windsurf> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Busybox hwclock failing to build with musl RISC-V 32-bit: SYS_settimeofday undefined On Sun, Mar 03, 2024 at 03:36:11PM +0100, Thomas Petazzoni wrote: > Hello, > > The recently released musl 1.2.5 includes 32-bit RISC-V support. Turns > out that building Busybox 1.36.1 with this new musl version, on 32-bit > RISC-V, fails with: > > util-linux/hwclock.c: In function 'set_kernel_tz': > util-linux/hwclock.c:142:27: error: 'SYS_settimeofday' undeclared (first use in this function); did you mean 'xsettimeofday'? > 142 | int ret = syscall(SYS_settimeofday, NULL, tz); > | ^~~~~~~~~~~~~~~~ > | xsettimeofday > util-linux/hwclock.c:142:27: note: each undeclared identifier is reported only once for each function it appears in > > Busybox already includes some slightly convoluted sorcery to deal with > musl: > > static void set_kernel_tz(const struct timezone *tz) > { > #if LIBC_IS_MUSL > /* musl libc does not pass tz argument to syscall > * because "it's deprecated by POSIX, therefore it's fine > * if we gratuitously break stuff" :( > */ > #if !defined(SYS_settimeofday) && defined(SYS_settimeofday_time32) > # define SYS_settimeofday SYS_settimeofday_time32 > #endif > int ret = syscall(SYS_settimeofday, NULL, tz); > #else > int ret = settimeofday(NULL, tz); > #endif > if (ret) > bb_simple_perror_msg_and_die("settimeofday"); > } > > I am not sure whether this is a Busybox problem or a musl problem, > which is why I'm cross-posting on both mailing lists. > > Thanks a lot in advance for your feedback, It was broken by this commit which is completely wrong: https://git.busybox.net/busybox/commit/util-linux/hwclock.c?id=9e262f13c2e53490d69d3112ffd718c27de04d1f Especially the comment about the reason musl does not do this is wrong. It's very intentional that we do not pass this to the kernel. musl is not a GNU/Linux clone. I've been through this with Toybox folks too, where there's a more detailed explanation in this PR thread: https://github.com/landley/toybox/pull/479 Since it's invasive enough to be hard to carry a revert, just revert the first hunk (wrong detection for musl) and the rest will become a no-op. As a Busybox *user*, I deem the change in this patch actively hostile. If a musl-based system, which has always been designed *not to use* kernel-timezone functionality that breaks fatfs timestamps and does other harmful things, suddenly started setting it at boot because of a new patch to Busybox, and thereby corrupted my data, I would be rather infuriated. If Busybox really wants to do this, they need to figure out how to do it on archs that do not have SYS_settimeofday (such as riscv32). That was a problem for glibc too when they did their time64 stuff. Because musl has never supported this behavior, we had nothing to do to fix it for time64. But if they stick with this, distros are going to need to carry a patch to patch it out, so that users' timestamps don't get messed up. Rich