[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Jun 2022 10:57:22 -0400
From: Rich Felker <dalias@...c.org>
To: Zev Levy Stevenson <zevlevys@...il.com>
Cc: Arnd Bergmann <arnd@...nel.org>, musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
