From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2D4A41F461 for ; Fri, 19 Jul 2019 17:44:45 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=b2GDKYtqzecPMpTM KgRIA4EZs9SilimHiFYt/XWjm76aLdZ5Q/va6kSWQTxmKuMYzZfQc5FvChqVjZeO wtubLSdc7UlCJxWNmoajsL9SAxLsy1OfqLLQR+I5xYwWvJBHWOefHYEFfscjxSk8 8mr5asx93QCWDaRa/IZK53FoIWw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=Z+o04X5CkRtT4+55oCfn+w KuMfk=; b=k/zfEvx/1fpWmuz1f7PGOLHTAVIvrfbcyFaf2Z2kTY9oUzKdkfjfLP 3pqEn9HvDc4Gyb1O7/QgpTXCm+sFVdb3AHbmrLp1oFxgFE82mSHHMuKPG5PvuGSo VWrL9cqm8WKTSUbRTjAasLitg61mFg7VFmQVxAtdCJ9kBM9t+Up0U= Received: (qmail 64331 invoked by alias); 19 Jul 2019 17:44:42 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 64323 invoked by uid 89); 19 Jul 2019 17:44:42 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f195.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wJHmbJa8IeHMXFO2jv8hNkuz8kGy/NYluR0A4YX74os=; b=opYlA49t1Od7zA2IEYVymqzUf3bdbWVslqQ7HX3PPiIZKwFy/fkuBbpBDpJRotKwy2 JZQGr6M1lG4l6P5twRyfq+Z2zhn6A3mvJQH29BuwXGzb0/TkxLdc76tTy0QNRN8mZWjb SfIli3gZWzios+beK7P1cw7nq9WVVRQN5cyaEppGZ8SdzfqgT6Eg/uyzXYJMgSphT+5D e/r76oQeINI9RjFZ9ynFvvFqx6a7gLfLF+HVGm47gRZmmixGtGdXqK3KW8sauCzy85IP ktgIvAlZl098/eIkHBuXZgknjNDoYEh5ysAJZc5oFPO1r8hLzx5Vrf+xl9Tqt56pHjhW MErw== To: Rich Felker Cc: Florian Weimer , libc-alpha@sourceware.org References: <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> <87ftn3xija.fsf@oldenburg2.str.redhat.com> <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> <20190719030639.GV1506@brightrain.aerifal.cx> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Accelerating Y2038 glibc fixes Message-ID: Date: Fri, 19 Jul 2019 14:44:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190719030639.GV1506@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 19/07/2019 00:06, Rich Felker wrote: > On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote: >> >> >> On 18/07/2019 16:13, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>> So what about to not add a user-selected way to set the time_t size >>>> (as off_t) and just enable time64_t support and sets is as default for >>>> build with a minimum kernel of v5.1 (if I recall correctly as being the >>>> one that added time64 support)? >>> >>> Does this mean that some developers see a glibc 2.31 with a 32-bit >>> time_t on i386, and others see a 64-bit time_t? >>> >>>> It will move all time32 support as compat symbols for the required ABI, >>>> without an option to select it through a build flag. Newer ports will >>>> just have the expected symbol names, no tinkering needed. >>> >>> But if we build glibc with pre-5.1 kernel headers, you will get the >>> legacy interface? >> >> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION >> when time64 is used. So, depending on how glibc is built, developers >> will indeed see a different time_t. >> >> Legacy builds won't build any time64 support, even with newer kernels. >> Build set with --enable-kernel will automatically set time_t as time64 >> and redirect the required interfaces to the new symbols ones (similar >> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default). >> >> Newer 32-bit ports won't require anything like this as expected. >> >> I still think that in long term this initial bump transition is better >> than to the complexity from mixed support. > > I see no reason for it to depend on the minimum kernel version glibc > is built for. You should be able to build glibc that runs on the > oldest still-supported kernels and that uses 64-bit time_t in the > application-facing ABI. > > If built with --enable-kernel new enough, the fallback code to use old > syscalls when the time64 ones fail with ENOSYS can be omitted. If not, > the time64 syscalls are tried first, and if they fail, the old > syscalls are used and the results converted. > > This is what musl has always planned to do regardless of whether we go > with a hard ABI break or symbol redirection. "Only works on > bleeding-edge kernels" is a sure way to make sure nobody uses the new > thing, resulting in continued production of legacy binaries that are > ticking timebombs far into the future, and all the exploding popcorn > when 2038 approaches... I am aiming for make the required changes less complex and allow the distributions to have a way to actually set or not whether to support time64, since you can still build glibc aiming for default minimum (3.2) while still providing a time64 enabled kernel. I personally prefer to just make the switch based on release rather than a configure option. And I do agree with you that it is feasible to just make the switch on glibc 2.31 for all 32-bit architectures and move on. However we will need to take care of glibc some conventions, so instead of just -- #if __LINUX_KERNEL_VERSION >= 0x050100 # define __ASSUME_TIME64_SYSCALLS 1 #endif int syscall_name (...) { #ifdef __ASSUME_TIME64_SYSCALLS return INLINE_SYSCALL_CALL (syscall64, ...); #else return INLINE_SYSCALL_CALL (syscall, ...); #endif } --- We will need to have something like: -- #if __LINUX_KERNEL_VERSION >= 0x050100 >= 0x050100 # define __ASSUME_TIME64_SYSCALLS 1 #endif int syscall_name (args...) { #ifdef __ASSUME_TIME64_SYSCALLS return INLINE_SYSCALL_CALL (syscall64, args...); #else int ret; # ifdef __NR_syscall64 static int syscall_name_supported = 1; if (atomic_read_relaxed (&syscall_name_supported) == 1) { ret = INLINE_SYSCALL_CALL (syscall64, args...); if (ret == 0 || errno != ENOSYS) return ret; atomic_store_relaxed (&syscall_name_supported, 0) } # endif /* __NR_syscall64 */ ret = INLINE_SYSCALL_CALL (syscall, args...); if (ret == 0) ret = convert_syscall_time_to_time64 (args, ...); return ret; #endif } -- For the syscall implementation. We will have some more complexity to handle vDSO, but it should be simplified with my refactor.