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 9B1CA1F4B6 for ; Thu, 18 Jul 2019 15:46:24 +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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=yY/f 70Mj/Gl4872qfZveNw6BI+yXb8JmYKonaJh5OpiwFYwoncUAI1IDynPaPNSZtP7y 1iGlzaCbJmeCIsK4Tr+W0Era4A7DcVEv/b+Wznytw5/kiJjcvhyi6vUjekhz3QE9 av2YQxtEc6kvrPH3d9PTAdHVqlVpl6BXMD/523c= 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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=sdp9/FuBF3 WdGI4xsnDEAMKeVxA=; b=cNcAavsTQJEOHNrB4RMilOhk8mBuChUv+2diZBsI07 D5HE8i4aQKVUO3dfKdv+ZXZA5us2Jce6wiquE55XmfIRessVasqhF5Y1CuMWlQOo bN9G0K0z1qfppPUnTATDxSmkp7VjY4+MYQmSg3iiVcLofL++lLKmdkFLX1tXKJc2 E= Received: (qmail 88098 invoked by alias); 18 Jul 2019 15:46:22 -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 88089 invoked by uid 89); 18 Jul 2019 15:46:22 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Date: Thu, 18 Jul 2019 11:46:13 -0400 From: Rich Felker To: Florian Weimer Cc: Lukasz Majewski , Arnd Bergmann , Wolfgang Denk , GNU C Library , Joseph Myers Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190718154613.GS1506@brightrain.aerifal.cx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhlbz9c4.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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. Rich