[prev in list] [next in list] [prev in thread] [next in thread] 

List:       musl
Subject:    Re: [musl] [PATCH 00/18] time64: always prefer time64 syscalls
From:       Alexander Lobakin <alobakin () pm ! me>
Date:       2020-12-28 11:11:38
Message-ID: 20201228111114.4131-1-alobakin () pm ! me
[Download RAW message or body]

From: Rich Felker <dalias@aerifal.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=3Dn 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

[prev in list] [next in list] [prev in thread] [next in thread]