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.