[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220614232826.GJ7074@brightrain.aerifal.cx>
Date: Tue, 14 Jun 2022 19:28:27 -0400
From: Rich Felker <dalias@...c.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: musl@...ts.openwall.com
Subject: Re: Question about musl's time() implementation in time.c
On Tue, Jun 14, 2022 at 11:11:32PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 14, 2022 at 10:49 PM Rich Felker <dalias@...c.org> wrote:
> > On Tue, Jun 14, 2022 at 10:37:25PM +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 14, 2022 at 7:00 PM Rich Felker <dalias@...c.org> wrote:
> > > > On Tue, Jun 14, 2022 at 06:50:40PM +0200, Arnd Bergmann wrote:
> > > > > 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.
> > >
> > > I can't find any reference to what the correct clock is here,
> > > are you sure that this is specified at all? The decision to use the coarse
> > > time in the kernel is definitely intentional, as reading the hardware
> > > clocksource can be expensive (depending on the hardware), and
> > > changing the behavior would likely break applications that rely on
> > > it being the coarse clock.
> >
> > POSIX specifies operations that set the file timestamps in terms of
> > the system (CLOCK_REALTIME) clock, not a weird implementation-defined
> > alternate clock.
> >
> > Maybe you're right that getting the correct clock is costly on some
> > archs, but it's almost surely not on any arch that admits vdso
> > clock_gettime. And "race that causes applications to see wrong
> > ordering of filesystem operations with respect to other activity for
> > the sake of performance" does not seem like a good idea.
>
> The thing is that a lot of file systems would still behave the same way
> because they round times down to a filesystem specific resolution,
> often one microsecond or one second, while the kernel time accounting
> is in nanoseconds. There have been discussions about an interface
> to find out what the actual resolution on a given mount point is (similar
> to clock_getres), but that never made it in. The guarantees that you
> get from file systems at the moment are:
It's normal that they may be rounded down the the filesystem timestamp
granularity. I thought what was going on here was worse.
> - the timestamp is always rounded down, not up, so a newly
> created file never gets a timestamp that is newer than either
> CLOCK_REALTIME or CLOCK_REALTIME_COARSE as
> reported by a subsequent clock_gettime()/gettimeofday()/time().
>
> - the in-memory timestamp is the same that you read back
> after umount/mount, and gets adjusted for both resolution
> and range of the on-disk representation.
>
> - any file system that supports timestamps (some always
> report tv_sec=0) set the timestamps to at most three
> seconds before the current time as read by an earlier
> time() syscall.
>
> Making it use CLOCK_REALTIME instead of
> CLOCK_REALTIME_COARSE would improve the third
> guarantee so it could be within two seconds (or one second
> on file systems with full-second resolution like ext3), but would
> break the first rule by making it report timestamps that can
> be either before or after the time reported by the time() syscall.
OK, the time syscall doing the wrong thing here (using a different
clock that's not correctly ordered with respect to CLOCK_REALTIME)
seems to be the worst problem here -- if I'm understanding it right.
The filesystem issue might be a non-issue if it's truly equivalent to
just having coarser fs timestamp granularity, which is allowed.
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.
