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.4 required=5.0 tests=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 11209 invoked from network); 15 Jun 2022 16:55:24 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Jun 2022 16:55:24 -0000 Received: (qmail 7560 invoked by uid 550); 15 Jun 2022 16:55:20 -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 7516 invoked from network); 15 Jun 2022 16:55:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K8Qz7Vs9q7nXvzUppMlOI1ipfpO9oprPDhdKtEoC/cE=; b=aoMavuh7wK4rAf319BPW0UnFM7vqpdOqzns9SsFphs2vsczwbT4Lq5B7c8AJiy4fsR YNvD1jZMhUpjTiHq0KhSEvVXKEk4QzLFc64Qb20BNTTWXp2GP9jNoA8XCe0iijZUr2Y3 lxFtFXjZ5JswRu7VwN/Y1AWd3QHuBlrMBXevga1RCbh/1oF+BPecssT/Ou8vDxFAWW4v WKujbRpZ3I7gcY+YQ5FrXtasAAsHA/p9Np68Dmg0oG4/KkzfefjAdT5yfMoeqa2tplys ztn3FUfXz/At8hF3Am46sL3qsT80x7dGttJqjPu/28uDNdFWGRS48f9qImyilU75iNr4 kb6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K8Qz7Vs9q7nXvzUppMlOI1ipfpO9oprPDhdKtEoC/cE=; b=f8f3kw9QnNjqdv8iAJJzGPAzgz43QpSl5nOonY+lY9/J272KHhvmVGSXWjFO5o/xh5 vgrnzOIzDZZvPHWHN1LMtgNk3wfH0d925YigaZH33hMHC6KgEPxWgtq85LMPTHCZTwFY Km2l/zZGVamdf/08jL4L7L0Es/4bwnqcNe2zOgIKKitqM4N7UraehOmXFKyi0xRIfC5I IYU4cw+k8Gi8icgz4fRXjiorenwdFF5OcCNQh68RXmgXVoiM0v+JB8yADkS4SsoDIgqn 4nGL4/0Eh+K4KKEdeAyFP+hLWLaAROQG6ljCtLmXCDKzpoj1m/7+ZZXl7bFmKXwO438X u/XQ== X-Gm-Message-State: AJIora9TlHauZQBTjfQQCukPaFYTsrh22oGfw1zk0L3KTXeEPWMVOe37 LaIKnqkrASRH1ZNr9VS3xzuORQ== X-Google-Smtp-Source: AGRyM1umrgLajayXr/hGrxoLhCuR8bRhZPsFgQ+EIAAt6jl3I/xAwvzaXV0zsGsvJ0MpysAPh6ATUA== X-Received: by 2002:a17:90b:4b4b:b0:1e8:9e0e:c362 with SMTP id mi11-20020a17090b4b4b00b001e89e0ec362mr352044pjb.187.1655312106819; Wed, 15 Jun 2022 09:55:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) From: Adhemerval Zanella In-Reply-To: Date: Wed, 15 Jun 2022 09:55:04 -0700 Cc: musl@lists.openwall.com, John Stultz , Stephen Boyd , Linux Kernel Mailing List , Thomas Gleixner Content-Transfer-Encoding: quoted-printable Message-Id: <929C8485-D7F2-470A-B704-8068540DC358@linaro.org> References: <20220607163053.GD7074@brightrain.aerifal.cx> <20220614170013.GH7074@brightrain.aerifal.cx> <20220614204900.GI7074@brightrain.aerifal.cx> <20220614232826.GJ7074@brightrain.aerifal.cx> To: Arnd Bergmann X-Mailer: Apple Mail (2.3696.100.31) Subject: Re: [musl] Question about musl's time() implementation in time.c > On 15 Jun 2022, at 05:09, Arnd Bergmann wrote: >=20 > On Wed, Jun 15, 2022 at 1:28 AM Rich Felker wrote: >> On Tue, Jun 14, 2022 at 11:11:32PM +0200, Arnd Bergmann wrote: >>>=20 >>> 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: >>=20 >> It's normal that they may be rounded down the the filesystem = timestamp >> granularity. I thought what was going on here was worse. >=20 > It gets rounded down twice: first down to the start of the current > timer tick, which is at an arbitrary nanosecond value in the past = 10ms, > and then to the resolution of the file system. The result is that the > file timestamp can point to a slightly earlier value, up to max(timer = tick > cycle, fs resolution) before the actual nanosecond value. We don't > advertise the granule of the file system though, so I would expect > this to be within the expected behavior. >=20 >> 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. >=20 > Adding the kernel timekeeping maintainers to Cc. I think this is a > reasonable argument, but it goes against the current behavior. >=20 > We have four implementations of the time() syscall that one would > commonly encounter: >=20 > - The kernel syscall, using (effectively) CLOCK_REALTIME_COARSE > - The kernel vdso, using (effectively) CLOCK_REALTIME_COARSE > - The glibc interface, calling = __clock_gettime64(CLOCK_REALTIME_COARSE, ...) > - The musl interface, calling __clock_gettime64(CLOCK_REALTIME, ...) >=20 > So even if everyone agrees that the musl implementation is the > correct one, I think both linux and glibc are more likely to stick = with > the traditional behavior to avoid breaking user space code such as the > libc-test case that Zev brought up initially. At least Adhemerval's > time() implementation in glibc[1] appears to have done this = intentionally, > while the Linux implementation has simply never changed this in an > incompatible way since Linux-0.01 added time() and 0.99.13k added > the high-resolution gettimeofday(). >=20 > Arnd >=20 > [1] https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3D0d56378= 349 Indeed I have changed glibc to be consistent on all architectures to = mimic kernel behavior time syscall and avoid this very issue. We did not have a = consistent implementation before, so glibc varied depending of architecture and = kernel version whether it uses CLOCK_REALTIME or CLOCK_REALTIME_COARSE. If kernel does change to make time() use CLOCK_REALTIME, it would make sense to make glibc __clock_gettime64 to use it as well. We will also = need to either disable time vDSO usage on x86 and powerpc or make kernel = implementation=09 to use CLOCK_REALTIME as well.