[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Jun 2021 00:16:40 +0200
From: Martin Vajnar <martin.vajnar@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: Backwards kernel compatibility
Hi, Rich,
út 25. 5. 2021 v 0:00 odesílatel Rich Felker <dalias@...c.org> napsal:
>
> 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.
Since updating the kernel is not an option for me, I prepared patch
implementing memorizing failed syscall attempt on the time64 variants
and on statx syscall, so on next attempt it will skip them and use
fallback directly. Attaching the patch in case someone is solving the
same issue. Please, let me know, if this approach would be something
interesting for upstreaming and if so, if there are any changes I
should make.
> 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
Regards,
Martin
View attachment "0001-store-fallback-paths-for-kernels-without-time64-stat.patch" of type "text/x-patch" (23861 bytes)
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.
