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 26932 invoked from network); 1 Dec 2022 15:11:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Dec 2022 15:11:53 -0000 Received: (qmail 5300 invoked by uid 550); 1 Dec 2022 15:11:50 -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 5264 invoked from network); 1 Dec 2022 15:11:49 -0000 Date: Thu, 1 Dec 2022 10:11:36 -0500 From: Rich Felker To: Gregor Jasny Cc: musl@lists.openwall.com Message-ID: <20221201151136.GT29905@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Prefer monotonic clock for DNS lookup timeouts On Thu, Dec 01, 2022 at 12:24:47PM +0100, Gregor Jasny wrote: > Hello, > > while looking for a reason for a failed DNS resolve I noticed that > the mtime function which is used to calculate and decide on the > timeout uses the wall clock instead of a monotonic clock: > > static unsigned long mtime() > { > struct timespec ts; > clock_gettime(CLOCK_REALTIME, &ts); > return (unsigned long)ts.tv_sec * 1000 > + ts.tv_nsec / 1000000; > } > > http://git.musl-libc.org/cgit/musl/tree/src/network/res_msend.c#n28 > > Is this a bug or intentional? 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" (>=2.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 >=2.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...) 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: 1. Have the above mtime() function fall back to CLOCK_REALTIME on ENOSYS, or 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. 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. Rich