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 18932 invoked from network); 16 Jun 2022 14:57:39 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Jun 2022 14:57:39 -0000 Received: (qmail 19772 invoked by uid 550); 16 Jun 2022 14:57:36 -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 19740 invoked from network); 16 Jun 2022 14:57:35 -0000 Date: Thu, 16 Jun 2022 10:57:22 -0400 From: Rich Felker To: Zev Levy Stevenson Cc: Arnd Bergmann , musl@lists.openwall.com Message-ID: <20220616145721.GK7074@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 Fri, Jun 10, 2022 at 11:52:50AM +0300, 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. Going back to the issue that motivated this thread: perhaps libc-test should not use time(0) here but instead a second tmpfile() with a write to it followed by fstat, to get a timestamp out of the (same, temp) filesystem. Then it's not encoding any assumption about correct ordering between realtime clock and fs timestamps, which might be broken by fs timestamp granularity or the kernel issue discussed in this thread. It's only encoding an assumption that timestamps on the same filesystem are correctly ordered with respect to each other (which is necessary in order for make, etc. to work right). Rich