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 056C81F461 for ; Thu, 18 Jul 2019 16:43:36 +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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=BKEd3FTmK82Bd81n lhrsxzGOTiQXogYFH5oFSy6YOrrtW4J9T3DWVRkVvaCei4A/alFbzqNLR4QDjbEG giAT4r8t4IQwprDBV2MecgZS7FsAalNjLD3WcbtbY7Dk/NXQu58sP0VYNXG+SS7c yrAyytQ2vA3f+Q8xjSRvEkHfbSA= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=0duWcXi7HPfGrsbaNcDTn1 xUs44=; b=n+xWlAhsRXddGt9QL8/8i9Ogyz7jDwx4awigGWUJw1nTj3W5NmP3DT B642pR2RTxdEdYlcjZ4JJt6iDfQhAZyIyf0BD2fvLeEppgZKh928hV9VWCOoVbIE UQBt/x/VPIKcK9H0fj3tEhPOokp6pdATfMFfU4FQWLUV+tZZyTFKI= Received: (qmail 67667 invoked by alias); 18 Jul 2019 16:43:34 -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 67659 invoked by uid 89); 18 Jul 2019 16:43:34 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qt1n5JIF6REr63b46w37b5KLDvmrgjkMlEVXqKwXWp8=; b=E4VhbhDkVq8asOCW8oItuyAG4mWgDyfsooZDw04pWDl3rBiAc2JmR9l3qwNZofkU4s SiCiqBqxc48Ec7Ei0DN5OPsULEi91ZAkzXTQiZ7R88zNbAHh+bSb1yGZN+hNkAwDf8D2 jpphfHvH+FfI/D5ZKDAn3ULhgObipaGhMhrNux5mMWnMymGYDXmbbVl1NdqM5lf6yRcX e3Du22NhW/jghqMZU/4BQhvj2digNLOmCwrP+ZmQHzog5D1zrcOUNiPkisYgNo0PslIk jqsNe9UFqYaMhkcHgKITdcxUZZBsaB7fL84rhJiR4hAdImMconbYxtTAmdZxsKY4xCzI sIWg== Subject: Re: Accelerating Y2038 glibc fixes To: libc-alpha@sourceware.org References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <20190717175026.GM1506@brightrain.aerifal.cx> <20190717235748.2552834a@jawa> <20190718144715.GA11800@brightrain.aerifal.cx> <87zhlbz9c4.fsf@oldenburg2.str.redhat.com> <20190718154613.GS1506@brightrain.aerifal.cx> From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: Date: Thu, 18 Jul 2019 13:43:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190718154613.GS1506@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 18/07/2019 12:46, Rich Felker wrote: > On Thu, Jul 18, 2019 at 04:49:31PM +0200, Florian Weimer wrote: >> * Rich Felker: >> >>> On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote: >>>> Note: >>>> >>>> [1] - >>>> https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019 >>>> >>>> [2] - https://github.com/lmajewski/y2038-tests >>>> >>>> [3] - >>>> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29 >>>> >>>> [4] - https://github.com/lmajewski/meta-y2038/tree/master >>> >>> Some findings here that need correction: >>> >>> [1] is completely missing the sysvipc interfaces affected, and [3] >>> fails to document them as affected because the structs are variadic >>> arguments not declared ones. Fortunately, this means we can get away >>> without actually replacing the functions, and instead define new >>> command numbers to perform the translation. When doing this, glibc >>> should follow musl and correct other bugs in these structs: for >>> example, struct ipc_perm's mode field has the wrong type on some archs >>> (short instead of mode_t; only makes a difference on big endian). >> >> Do the musl types match the kernel types? > > Largely, since the kernel also left padding, but in the wrong order > for big endian. So instead of short+padding for mode on affected > archs, we have mode_t mode. On big endian variants of these archs, > this requires some fixup code to swap the upper/lower 16 bits. > > With time64, if you're bothering to decode the extra time bits (on > most archs these are in adjacent padding and just need endian swapping > on big endian; on some archs they're in non-adjacent padding) already > then it's no big deal to fix the mode_t at the same time. > > Note that on most archs, fixing these structs for time64 is just > replacing the 32-bit time_t and adjacent padding with a 64-bit time_t. > But on the exceptions (probably mips, because eew..) the struct needs > more significant changes. > This is BZ#18231 and I started to work on this some time ago. The main issue is not really fix it, but consolidate all the implementations to use a generic header for msg.h, sem.h, and shm.h, while providing compat symbol if it were the case. I will try to check this out again, since eventually I think we will need to get back to avoid a complicate support for time64.