From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62807 invoked by alias); 13 Sep 2018 10:48:44 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 62664 invoked by uid 89); 13 Sep 2018 10:48:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f195.google.com MIME-Version: 1.0 References: <53924daa4b51c0d552d17d3c5fd9aea09f9fc4b2.1536720821.git.han_mao@c-sky.com> <9466b02a-ddca-9baf-c9b5-83d06af3a5fa@redhat.com> In-Reply-To: <9466b02a-ddca-9baf-c9b5-83d06af3a5fa@redhat.com> From: Arnd Bergmann Date: Thu, 13 Sep 2018 10:48:00 -0000 Message-ID: Subject: Re: struct elf_prstatus and Y2038 (was: Re: [PATCH v4 06/13] C-SKY: Linux ABI) To: Florian Weimer Cc: Joseph Myers , Mao Han , GNU C Library , c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-09/txt/msg00179.txt.bz2 On Wed, Sep 12, 2018 at 11:28 PM Florian Weimer wrote: > > On 09/12/2018 05:34 PM, Arnd Bergmann wrote: > > Speaking of this file, I think we still need a solution for elf_prstatus > > containing a 'timeval' after time_t becomes 64-bit wide. I actually > > have a patch to change the kernel header file declaring the > > same structure, but I had not realized that glibc contains another > > copy. > > > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign mentions > > that type, but not what to do about it. What I did in the kernel > > was to change the type of pr_utime/pr_stime/pr_cutime/pr_cstime > > to something that keeps using 'long' fields. Given that we can't > > change the file format in an incompatible way, and that 32-bit > > is sufficient here, that seemed like the most appropriate solution. > > Keeping 32 bits there looks reasonable. I thought we had a port where > time_t isn't long, but that doesn't seem to be the case. Ok. I'll change it to 'struct __kernel_old_timeval' in the kernel headers then, keeping the existing definition we have for timeval. I did that patch a while ago, but think I've never posted it for inclusion so far. The same thing also gets used in the implementation for the wait4()/waitid() and getrusage() syscalls, which carry the same data as the core file, as well as the various VDSO implementations that we can't change over. I'm still undecided on whether we want a version of waitid and getrusage that takes a 64-bit timespec or 64-bit timeval for consistency, or just let the libc deal with the conversion from the 32-bit timeval here. > Ah, I think it's actually s390, where suseconds_t is int, not long. Odd: in the kernel, suseconds_t is long on s390, but int on sparc and parisc. Were you thinking of sparc64 instead of s390 maybe? I would guess that parisc64 is actually wrong here, but since there are not a lot of users on parisc and they tend to run 32-bit user space, it's plausible that this never got caught. I totally missed the sparc/parisc oddity about suseconds_t in the past, I'll have to modify my patch for that. Arnd