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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14141 invoked from network); 30 Dec 2022 03:21:28 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2022 03:21:28 -0000 Received: (qmail 1202 invoked by uid 550); 30 Dec 2022 03:21:25 -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 1158 invoked from network); 30 Dec 2022 03:21:24 -0000 From: "A. Wilcox" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Date: Thu, 29 Dec 2022 21:20:34 -0600 References: <20221201151136.GT29905@brightrain.aerifal.cx> To: musl@lists.openwall.com In-Reply-To: <20221201151136.GT29905@brightrain.aerifal.cx> Message-Id: <0737A458-7E17-4C2C-B702-7A40FAA6151A@adelielinux.org> X-Mailer: Apple Mail (2.3731.200.110.1.12) Subject: Re: [musl] Prefer monotonic clock for DNS lookup timeouts On Dec 1, 2022, at 9:11 AM, Rich Felker wrote: >=20 >> http://git.musl-libc.org/cgit/musl/tree/src/network/res_msend.c#n28 >>=20 >> Is this a bug or intentional? >=20 > It was intentional, based on a belief that the monotonic clock might > not be present on all kernels. That seems to be incorrect for the > range of versions we "support" (>=3D2.6.0) but some archs unofficially > work back to mid 2.4.x or earlier with limited functionality (no > threads). Note for example that clock_gettime has fallback to the > gettimeofday syscall despite all kernels >=3D2.6.0 having = clock_gettime > (though was it perhaps gated under some CONFIG_ for "realtime > features" at some point? this probably calls for some research...) >=20 > Switching to monotonic here has been on my radar for a while. I see > two decent ways to do it without any possibility of regression: >=20 > 1. Have the above mtime() function fall back to CLOCK_REALTIME on > ENOSYS, or >=20 > 2. Go through with integrating a fallback for CLOCK_MONOTONIC I've had > in draft for a long time that works on ancient kernels. It works by > combining the seconds-resolution time from SYS_sysinfo uptime with > the finer-grained-but-wrapping jiffy count from SYS_times too get a > monotonic jiffies-resolution uptime. >=20 > The latter is cute/fun but a little bit of work to get right and I'm > not sure it's sufficiently useful to justify doing it. Option 1 seems > very reasonable. >=20 > Rich clock_gettime was added in 2.5.63 and 2.6.0 and was always obj-y. There is no CONFIG knob that controls it in early 2.6, though I stopped my search at 2.6.16. I have written this patch out, but I don=E2=80=99t have a box without = monotonic clock, so I can=E2=80=99t test the validity of the patch. I will send = the patch to the list for review. Best, -A.=