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 24283 invoked from network); 14 Jun 2022 17:00:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 17:00:30 -0000 Received: (qmail 1086 invoked by uid 550); 14 Jun 2022 17:00:28 -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 1050 invoked from network); 14 Jun 2022 17:00:27 -0000 Date: Tue, 14 Jun 2022 13:00:14 -0400 From: Rich Felker To: Arnd Bergmann Cc: musl@lists.openwall.com Message-ID: <20220614170013.GH7074@brightrain.aerifal.cx> References: <20220607163053.GD7074@brightrain.aerifal.cx> 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 14, 2022 at 06:50:40PM +0200, Arnd Bergmann wrote: > On Fri, Jun 10, 2022 at 10:53 AM Zev Levy Stevenson wrote: > > > > Thank you for the responses, those reasons make sense to me. We are using a very customized toolchain but the kernel itself is standard. > > We looked into it a bit further and we were able to reproduce the issue with a clean musl-gcc toolchain for x86_64 (version 1.2.2) on a Linux kernel that we took from a standard Ubuntu distribution. > > Specifically, tests in the libc-test suite (https://wiki.musl-libc.org/libc-test.html) using the time() function fail sometimes, e.g. src/functional/utime.c, which fails on about ~3-4 runs in every 1,000 runs. This can be reduced to this type of code failing: > > > > t = time(0); > > if(futimens(fd, ((struct timespec[2]){{.tv_nsec=UTIME_NOW},{.tv_nsec=UTIME_OMIT}})) != 0) return 1; > > if (fstat(fd, &st) != 0) return 1; > > if (st.st_atim.tv_sec < t) printf("time inconsistency\n"); > > > > When replacing the call to time(0) with a raw call to the Linux time() syscall the issue seems to disappear. On the other hand, using the clock_gettime syscall results in the same issue. > > Perhaps this is an issue with the Linux implementation of these syscalls / vdso functions, in which case further research may be required, or maybe such consistency when using different methods for measuring the system time doesn't have to be guaranteed, in which case the tests should probably be modified to allow for small inaccuracies such as the one described above. > > I think the problem here is likely the inconsistency between the > COCK_REALTIME and > CLOCK_REALTIME_COARSE domains. > > The time() syscall in the kernel is based on CLOCK_REALTIME_COARSE, while musl > uses CLOCK_REALTIME. The futimens() syscall in turn uses > CLOCK_REALTIME_COARSE. > > The coarse time can be up to one timer tick behind, so reading > CLOCK_REALTIME first > can give you the exact second with a small nanosecond value, while the > utime will still > set the previous value. > > Can you change the test case to check if the later time is less than > clock_getres(CLOCK_REALTIME_COARSE, ...) behind? This seems like a bug that the kernel uses the wrong clock for setting file timestamps. It can result in seeing events out-of-order (exactly as described in this thread). This should really be fixed or at least made switchable so users who care can fix it. Rich