[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 28 Dec 2020 11:11:38 +0000
From: Alexander Lobakin <alobakin@...me>
To: musl@...ts.openwall.com
Cc: Alexander Lobakin <alobakin@...me>, Rich Felker <dalias@...ifal.cx>
Subject: Re: [PATCH 00/18] time64: always prefer time64 syscalls
From: Rich Felker <dalias@...ifal.cx>
Date: Sun, 27 Dec 2020 16:52:19 -0500
> 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.
So, regarding the entire series, should I continue to work on v2
etc. or it's not worth it since CONFIG_COMPAT_32BIT_TIME is
considered _wrong_ -> not the thing that we should rely on?
> Rich
Thanks,
Al
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.
