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.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22800 invoked from network); 24 May 2021 22:00:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2021 22:00:19 -0000 Received: (qmail 32330 invoked by uid 550); 24 May 2021 22:00:17 -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 32312 invoked from network); 24 May 2021 22:00:16 -0000 Date: Mon, 24 May 2021 18:00:05 -0400 From: Rich Felker To: Martin Vajnar Cc: musl@lists.openwall.com, Markus Wichmann , Florian Weimer Message-ID: <20210524220004.GD2546@brightrain.aerifal.cx> References: <20210510185837.GD2031@voyager> 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] Backwards kernel compatibility On Mon, May 24, 2021 at 03:52:44PM +0200, Martin Vajnar wrote: > Hi, Markus, > > sorry for the late reply it was quite busy lately. You're describing > exactly the issue, we are facing in our project. We need to use old kernel > which we have only in binary form and have headers for it. At the same time > we would like to have the latest musl running on it. > > The problem we encounter is that for unsupported (or better said, not > supported yet) syscalls we get performance overhead because of the ENOSYS. Can you give some information on what syscalls these are and if/how you measured the performance overhead as being significant? > We see 2 options to approach this: > > 1. remove the syscalls manually/alter the code to not invoke them (hacky) > 2. during musl compile time (maybe even configure-time), parse the > supplied kernel headers and based on availability of syscalls use defines > to steer the code execution (more universal) > > Would the 2nd case be something that musl community would be interested in, > should we choose to implement it for the project? No, but hopefully there's a third option: identify whatever place the fallback is actual a performance bottleneck and do what we can to mitigate it. If it's really bad, saving the result might be an option, but we've tried to avoid that both for complexity reasons and because it could preclude fixing serious problems (like Y2038 EOL) by live-migrating processes to a newer kernel with new syscalls that avoid the bug. A better approach is just using the "oldest" syscall that can actually do the job, which we already try to do in most places in musl, only relying on the newer one for inputs that require it. However this is not possible for functions that read back a time, since the input is external (e.g. the system clock or the filesystem) and it's not known in advance whether the old syscall could represent the result. It *might* be plausible to memorize the result "new syscall not available" but drop that memory whenever we see a result that indicates a failure due to use of the outdated syscall. We're kinda already doing that with the vdso clock_gettime -- cgt_time32_wrap disables itself if it ever sees a negative value for seconds. An alternative approach, especially if this is a matter of time64, to avoid nonstandard binaries that would be non-future-proof, might be to patch your kernel with a loadable module that adds dumb translation layers for the syscalls that are performance bottlenecks. Rich