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 21754 invoked from network); 14 Jun 2022 20:49:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 20:49:16 -0000 Received: (qmail 23952 invoked by uid 550); 14 Jun 2022 20:49:14 -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 23916 invoked from network); 14 Jun 2022 20:49:13 -0000 Date: Tue, 14 Jun 2022 16:49:00 -0400 From: Rich Felker To: Arnd Bergmann Cc: musl@lists.openwall.com Message-ID: <20220614204900.GI7074@brightrain.aerifal.cx> References: <20220607163053.GD7074@brightrain.aerifal.cx> <20220614170013.GH7074@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 10:37:25PM +0200, Arnd Bergmann wrote: > On Tue, Jun 14, 2022 at 7:00 PM Rich Felker 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. Rich