From: Alexander Lobakin <alobakin@pm.me>
To: musl@lists.openwall.com
Cc: Alexander Lobakin <alobakin@pm.me>, Rich Felker <dalias@aerifal.cx>
Subject: Re: [musl] [PATCH 00/18] time64: always prefer time64 syscalls
Date: Mon, 28 Dec 2020 11:11:38 +0000 [thread overview]
Message-ID: <20201228111114.4131-1-alobakin@pm.me> (raw)
In-Reply-To: <20201227183842.22030-1-alobakin@pm.me>
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=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
prev parent reply other threads:[~2020-12-28 11:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-27 18:39 Alexander Lobakin
2020-12-27 18:40 ` [musl] [PATCH 01/18] clock_gettime: prefer time64 variant if available Alexander Lobakin
2020-12-27 18:40 ` [musl] [PATCH 02/18] clock_settime: " Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 03/18] clock_adjtime: try adjtimex at last Alexander Lobakin
2020-12-27 21:57 ` Rich Felker
2020-12-27 18:41 ` [musl] [PATCH 04/18] clock_getres: use time64 variant by default Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 05/18] clock_nanosleep: prefer time64 variant if available Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 06/18] timer_gettime: " Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 07/18] timer_settime: " Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 08/18] timerfd_gettime: " Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 09/18] timerfd_settime: " Alexander Lobakin
2020-12-27 18:41 ` [musl] [PATCH 10/18] utimensat: " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 11/18] pselect, select: prefer time64 variant of pselect6 " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 12/18] poll, ppoll: prefer time64 variant of ppoll " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 13/18] mq_timedsend: prefer time64 variant " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 14/18] mq_timedreceive: " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 15/18] semtimedop: prefer time64 variant of semtimedop " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 16/18] [rt_]sigtimedwait: prefer time64 variant " Alexander Lobakin
2020-12-27 18:42 ` [musl] [PATCH 17/18] futex: " Alexander Lobakin
2020-12-27 22:18 ` Rich Felker
2020-12-27 18:42 ` [musl] [PATCH 18/18] sched_rr_get_interval: use " Alexander Lobakin
2020-12-27 21:54 ` [musl] [PATCH 01/18] clock_gettime: prefer " Rich Felker
2020-12-27 21:52 ` [musl] [PATCH 00/18] time64: always prefer time64 syscalls Rich Felker
2020-12-28 11:11 ` Alexander Lobakin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201228111114.4131-1-alobakin@pm.me \
--to=alobakin@pm.me \
--cc=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).