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 20265 invoked from network); 14 Jun 2022 20:38:00 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 20:38:00 -0000 Received: (qmail 15464 invoked by uid 550); 14 Jun 2022 20:37:58 -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 15426 invoked from network); 14 Jun 2022 20:37:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655239064; bh=UO93QLs6DHtDozqT0yX8grUbOBv+Q6FuVAqyG9BGdmg=; h=References:In-Reply-To:From:Date:Subject:To:From; b=KrdD9oFAWXbrTN/X+HWc481s7iYK4HZxsL9vz7JvnKkXwWU2AY3OthbAXAn5Iooml GBQE4QKxWqwDKe6z2l2ZKErDwWl3owgIK/sa61i6v4sZ+7L1q6BN6+jnG+owMI6QB0 02LSLM9gyxfBJUwl/xlD04+RfeYyyNWWGVGyB/nbbbHpJdNFRIZ7Q8yx9mnMh3Mwwq VqH36o5t8yeW2+VbStwu25n86omqH8x3I5qL8fDd1VUO1l5aRj3/sWZTKJ9juu4h9L SUE/U9G8SP17OgI71bsOmI7y7HSxAkJX6KiPA5uqSMvNVnn1yL93GYgzp59h7QVm7d mxduuhUQkNrPw== X-Gm-Message-State: AJIora+Vp+qygs03Gddgu+tTzFIJr6AQ8VHdBD7+HuByXScFHFzpOXnT cGM57C/jyuYtkhYKDxQ+8RexrmkTBtAXcnje24s= X-Google-Smtp-Source: AGRyM1vgZApTzPgq/cUC2h1IN2Sz6FZqLYFgtSMmcN8xBw7sB3qWvN8s8WLyHSpNxcQNYApmP5JyXl9g78Re1GX611w= X-Received: by 2002:a81:ad7:0:b0:2e6:84de:3223 with SMTP id 206-20020a810ad7000000b002e684de3223mr7916466ywk.209.1655239063679; Tue, 14 Jun 2022 13:37:43 -0700 (PDT) MIME-Version: 1.0 References: <20220607163053.GD7074@brightrain.aerifal.cx> <20220614170013.GH7074@brightrain.aerifal.cx> In-Reply-To: <20220614170013.GH7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Tue, 14 Jun 2022 22:37:25 +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 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. Arnd