[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 May 2021 18:00:05 -0400
From: Rich Felker <dalias@...c.org>
To: Martin Vajnar <martin.vajnar@...il.com>
Cc: musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
