From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id DF7ED3877404 for ; Thu, 17 Jun 2021 17:41:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF7ED3877404 Received: by mail-qt1-x836.google.com with SMTP id t9so5386984qtw.7 for ; Thu, 17 Jun 2021 10:41:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nYuDQ/Ob5IhdnrvLPZ//6+vr+2ZBeRZDBIvIpUO/1qM=; b=Stnzbo9X2g8q2gwwej9/8sKvn3a61YlhrYVT5tnVVtYpkYnFncW0RACahlIYUElrQN /igWbleAcUxz9csnury7W7/UOuNQJIxAuSEgH008tribQzlDkYRgJn1au57ju1FS9wq2 vs9IA1NGsFKKLBAdfSYFKCSSFAHbZtcRxY1lxD6E5YeYFg8qzEquUkg/SB5SLeAiPscB g4deY/nKpLS2Y/AllibGWJvaVXpmd1EBtkD1ivTenp0nIvZ0YciiOdTOIlYygyksahzh 7+DkOEupGRYU5VFjKl+7owssg3QTSIy+ekHtbi6l4Fd8fA1KOfLDuri51MjZCEfDtF0W +55g== X-Gm-Message-State: AOAM533kFG/Y+goyX8IQssS4/jCGaqzVZ1dgisPQxJuLlWP3hi/uwQG8 olkLQaCyAzK+NXYdP2K2iAK3Ww== X-Google-Smtp-Source: ABdhPJwCdNIH3d9NCDkjS1fq6IjEkDFSBXFoW69Q2m7dNBS5q0g++8qopoOhPj3JgWwou733r+Efug== X-Received: by 2002:ac8:568b:: with SMTP id h11mr6365520qta.206.1623951706460; Thu, 17 Jun 2021 10:41:46 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id 16sm3575392qty.15.2021.06.17.10.41.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 10:41:46 -0700 (PDT) Subject: Re: [PATCH 00/18] More y2038 fixes To: Lukasz Majewski Cc: libc-alpha@sourceware.org, Carlos O'Donell References: <20210617115104.1359598-1-adhemerval.zanella@linaro.org> <20210617162021.52a63a3e@ktm> From: Adhemerval Zanella Message-ID: <188b5674-a34c-5c27-6332-9a549471cf90@linaro.org> Date: Thu, 17 Jun 2021 14:41:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210617162021.52a63a3e@ktm> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 17:41:48 -0000 On 17/06/2021 11:20, Lukasz Majewski wrote: > Hi Adhemerval, > >> Hi Carlos and Lukasz, >> >> This patchset adds more y2038 fixes that I would like to push for >> 2.34. The first two patches enable more internal y2038 usage on glibc >> and also for the installed programs. Making glibc the first consumer >> of these newer interfaces should improve coverage. >> > > Those two patches were already available for review for some time. > Indeed, by using 64-bit time internally we may have more testing > (sooner). Yes, but I changed slight the one that enabled the y2038 symbol on installed program to use apply the CFLAGS on module, instead of setting in each sub Makefile. > >> The next 6 patches removes an optimization I added on some specific >> syscall, where a global variable it atomically set once glibc detects >> that kernel supports 64-bit time. The problem with this approach >> breaks the usage case of live migration like CRIU or similar. > > I do recall that this optimization was to avoid performance regression > on legacy systems - to avoid issuing two syscalls (64 bit one and then > 32 bit one). Yes, but as I noted some interfaces don't really need to use the newer syscall in the compatibility mode (where glibc is build to support older kernels). This optimization is really tricky, since it incurs in some data races (I think to fully avoid it would require seq-cst atomic instead of relaxed ones) and it might break live migration. > >> Also >> for some interfaces that do not query information from kernel, most >> usages can be optimized away by either building glibc with a minimum >> 5.1 kernel or by using the 32-bit syscall for the common case. > > I do think that this approach (with classification of use cases based > on specified kernel version) aligns with how people will build setups > for those systems (at least I do it in this way for OE/Yocto). I think there will be specific cases where kernel update is not an option, but I think these will be really niches. > >> >> So the following patch implement this optimization for the interfaces >> that allows it. If the provided timeout can be fit in old 32-bit >> time_t, the old syscall is used instead. This optimization is only >> used for !__ASSUME_TIME64_SYSCALLS, otherwise the newer 64-bit >> syscall are used. > > Ok. > >> >> I checked this with 3 different configation which should cover most >> usages: >> >> - i686-linux-gnu on a 4.15 kernel and default --enable-kernel=3.2. >> This uses the 32-bit optimization to avoid calling the newer >> 64-bit syscall when possible. It also triggers and EOVERFLOW >> when 64-bit inputs are used without proper kernel support. > > Ok. > >> - i686-linux-gnu on a 5.11 kernel and default --enable-kernel=3.2. >> This will also use the 32-bit optimization, but it will always >> succeded due proper kernel support. > > Ok. > >> - i686-linux-gnu on a 5.11 kernel and with --enable-kernel=5.1. >> This enables __ASSUME_TIME64_SYSCALLS and only uses 64-bit >> time_t syscalls. > > Ok. > > BTW: I'm wondering when the minimal, supported Linux kernel version is > going to be moved forward? We usually follow the minimum LTS supported by Linux kernel developers.