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=-4.6 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 24674 invoked from network); 14 Jun 2022 21:12:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 21:12:07 -0000 Received: (qmail 8028 invoked by uid 550); 14 Jun 2022 21:12:05 -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 7992 invoked from network); 14 Jun 2022 21:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655241111; bh=L3HH5GFUyuIo+WO4aMReINotEKf66WSfUHBFzaDV6yY=; h=References:In-Reply-To:From:Date:Subject:To:From; b=oUP2OWzqYApVyOV8OjHZxUss8pj6kicmv1nrUswlfZbVGt6uM3yhfEvrrqB/0RiDj e2f0LZS88ECFDbSgFwBQ/WmUans9OeKd60tu2PdfBAVUkGUhgb2yQ0V+yD1nNgtFAP 7kghVx3+EE/qEjmlqaDSD1v20EeZwMJTPoNqFEbynFTFGQ3m2WeeUVohT0/bcoMALK A6MApurfpuHRlr02hwYjBdJT/SLVFd9Sb/hZxHtK8aSiG0/fpD9cpgQW09gS5QXwd2 PSfSao3ViFFGr7EVm6hJo+xoKldETqkXo7FVVqYayqN+zhYZHRB/TeQ5DCXmJIKKyd 7zx229uEeT8xA== X-Gm-Message-State: AJIora/xT0G9ijoURe3m9QO4eFQdcoQD9ars3jIIRyvzew32K4tq4z1S 7Y9JSkge/GC/3ifM9GMCwUwPdf7dC18A5HIUASY= X-Google-Smtp-Source: AGRyM1t6kNzkGrMG2t1HiSjpdv9OxZQ3Pm2+MG4gPF8lekTDCWmjeMwe+qlLBP/4ZROCU6YFcApCYESFAqCpDRryfMs= X-Received: by 2002:a81:190f:0:b0:313:43b8:155c with SMTP id 15-20020a81190f000000b0031343b8155cmr8049159ywz.495.1655241110744; Tue, 14 Jun 2022 14:11:50 -0700 (PDT) MIME-Version: 1.0 References: <20220607163053.GD7074@brightrain.aerifal.cx> <20220614170013.GH7074@brightrain.aerifal.cx> <20220614204900.GI7074@brightrain.aerifal.cx> In-Reply-To: <20220614204900.GI7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Tue, 14 Jun 2022 23:11:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Question about musl's time() implementation in time.c On Tue, Jun 14, 2022 at 10:49 PM Rich Felker 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 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: - 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. Arnd