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 8222 invoked from network); 15 Jun 2022 12:09:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Jun 2022 12:09:51 -0000 Received: (qmail 3565 invoked by uid 550); 15 Jun 2022 12:09:49 -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 3529 invoked from network); 15 Jun 2022 12:09:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655294975; bh=wkqJ/T68k9r2Oy7BU+HQ4jeUyx1IPklxlT7PijJ0qno=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hBt3Uo2tvXWSIPqwv/rcfFfzw4wpkZe0NdighutShKy/XFepXHmGKfhpOAhcrLwE+ taYYa+aQMG0lR76MSX8kXzT/y0AXI3zot9Q+2g6exppRyo0EIkqVCoXZCZLf9DivHG ljYfN30qUa6XOe65EtlPkcEaFvgUH0d5ZH1XHzhi2g/wH7ayjFNkBZNkEkcK6tgBnk jEAmuctIBOBzAK2CPoRWUKHbJdaWIYFbmSxpYykG0IZwYNjX5zJjeO1Q5o1njuFv8D WGQfXh0ytS8hRUveyO4X8+SU2LMi0T0QjKGzu3ZniBGrTdoGj19NJ7SRXaIMBiEYy/ ZWVl+MGVwqjKA== X-Gm-Message-State: AJIora9zdxs/rh43sM9fBC7By5SqNrrZVaR6Mm7Vj0F91Ja0HLAfUVRa siZ5dv+soNcmcu77ZUhJuHzdjmLthY4KNjzYzX8= X-Google-Smtp-Source: AGRyM1v1gZhuyIQo1km9VW5YHgE9Bpwhdz8KfSM7SWxOvp4o1BPT2oLt9iJz8J4qcgAqPHbKBgqAXKr5A03/M/GsKic= X-Received: by 2002:a0d:d84d:0:b0:314:2bfd:ddf3 with SMTP id a74-20020a0dd84d000000b003142bfdddf3mr11531420ywe.347.1655294974785; Wed, 15 Jun 2022 05:09:34 -0700 (PDT) MIME-Version: 1.0 References: <20220607163053.GD7074@brightrain.aerifal.cx> <20220614170013.GH7074@brightrain.aerifal.cx> <20220614204900.GI7074@brightrain.aerifal.cx> <20220614232826.GJ7074@brightrain.aerifal.cx> In-Reply-To: <20220614232826.GJ7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Wed, 15 Jun 2022 14:09:16 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Cc: John Stultz , Stephen Boyd , Linux Kernel Mailing List , Thomas Gleixner , Adhemerval Zanella Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Question about musl's time() implementation in time.c 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: > > > > 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. 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. > 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. Adding the kernel timekeeping maintainers to Cc. I think this is a reasonable argument, but it goes against the current behavior. We have four implementations of the time() syscall that one would commonly encounter: - 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, ...) 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(). Arnd [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0d56378349