From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17717 invoked from network); 7 Jun 2022 16:31:09 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Jun 2022 16:31:09 -0000 Received: (qmail 23847 invoked by uid 550); 7 Jun 2022 16:31:07 -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 23808 invoked from network); 7 Jun 2022 16:31:06 -0000 Date: Tue, 7 Jun 2022 12:30:53 -0400 From: Rich Felker To: Arnd Bergmann Cc: musl@lists.openwall.com, Zev Levy Stevenson Message-ID: <20220607163053.GD7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Question about musl's time() implementation in time.c On Tue, Jun 07, 2022 at 04:29:28PM +0200, Arnd Bergmann wrote: > On Tue, Jun 7, 2022 at 2:25 PM Zev Levy Stevenson wrote: > > > > Hi all, > > > > While running the libc-test test suite on a customized clang+musl > > build, I had trouble with some of the tests because of issues with > > time accuracy. > > I can go in detail if needed, but the problem seemed to boil down > > to the time() function in musl (in src/time/time.c) using a > > clock_gettime syscall (without vdso) instead of using the Linux > > time syscall that we expected it to use. Some other libc > > implementations use this syscall, and indeed after switching the > > syscall used in time () the tests passed, seemingly because the > > accuracy of the clocks used matched up. > > My main question is why musl's implementation doesn't use the time > > syscall, I'd be happy to hear if there was a special reason for > > this. > > The time() syscall on 32-bit architectures returns a 32-bit integer, > which overflows in y2038, only > clock_gettime() has the required range. This is indeed a good reason it can't be changed. Historically, though it was just a matter of avoiding code duplication. Due to the desire to support vdso and, clock_gettime requires a good deal of logic to find and use the vdso function and perform fallbacks if it's not available, or if the newer syscalls are not available. If time() did not use clock_gettime as its backend, but instead used separate kernel interfaces, this logic would need to be duplicated in time() too. It would also impose weird incentives for new archs to provide a time() syscall or vdso function, or would impose a requirement that we *also* duplicate the vdso logic to consume the vdso clock_gettime in time() if there's no vdso time(). If you've created an alternate kernel/syscall implementation where clock_gettime behaves badly and a legacy time syscall (or vdso function?) behaves good, that really doesn't seem like a good implementation choice. Especially if they produce mismatching output. I guess you could make a stretch argument that the implementation behaves as if someone is constantly changing the clock, but short of that, think it's even nonconforming (there's a single realtime clock and they're both supposed to return times in terms of it). Are there reasons you're trying to do things that way? Rich