[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201227215218.GA22981@brightrain.aerifal.cx>
Date: Sun, 27 Dec 2020 16:52:19 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Cc: Alexander Lobakin <alobakin@...me>
Subject: Re: [PATCH 00/18] time64: always prefer time64 syscalls
On Sun, Dec 27, 2020 at 06:39:03PM +0000, Alexander Lobakin wrote:
> Since Linux 4.18, there's an option CONFIG_COMPAT_32BIT_TIME that
> allows to ultimately test libc and userland programs if they are
> using the latest available syscall variants, time64 variants in
> particular.
> With this option turned off, old time32 syscalls don't get compiled
> at all. The same applies to some deprecated syscalls such as
> nanosleep.
CONFIG_COMPAT_32BIT_TIME is a violation of kernel stability policy and
was introduced as a bait-and-switch, with an initial promise that it
was a debugging option that would be hidden behind kernel hacking,
that somehow disappeared and ended up getting replaced with a
situation where it's turned off by allnoconfig. It should never be
enabled on any production system, as it precludes running any existing
binaries that depend on the kernel stability policy.
In general musl usually uses the oldest kernel APIs supporting the
needed functionality, and this is very intentional. It avoids costly
fallback procedures and situations where these code paths don't get
tested.
Aside from the principle of the matter, there are fairly large number
of call points where no fallback at all is needed, but one would be
needed if we used the new time64 syscalls first. This is because a lot
of the syscalls that CONFIG_COMPAT_32BIT_TIME=n wrongly removes
(again, in violation of kernel stability policy) are only
time-dependent for an optional timeout, and are usually called without
a timeout. This is particularly the case for futex, where each futex
call point would get considerably heavier if it had to support
fallbacks with a different syscall.
I haven't looked at the specifics of your patches yet to know if they
even got this. I will soon, but I'm pretty sure this is all just going
to have to be a no.
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.
