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=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no 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 CBEE71F463 for ; Sat, 21 Dec 2019 17:19:22 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=XiwX +mrvpilfPBMlTlDwDL3pP8VMM461OGIy+rzffrYEOyPM2Pl+Av2DdKmyBWhposUK XoBwxa4EtRO8x+esoPmvKhmuH77XOC37JM9krPBhuY3rOt+EaPTO2NNVxWaVe6aX UGAmE0vj29GTNxSiXjE5p5AZjPCxCFzfd6NlW2Y= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=xrPa+32/Ew risKQAgQ/Z0CYZ80o=; b=cgKC5duH8sB0V6pu1aottwNYReqfkxxcTtaBlqkLum NvWQjMp4CPRgqij4c9Xdvn3sXlKGFBsi4/vTyMqxoStEmidZLwJDyzKjdwAiu07x 2c9VXP21CLxPwn9BDT0JZefr7zXaiDdFMj2lYCJq4Gik+Ji7Fxb8lVGFzLebJsEg o= Received: (qmail 55296 invoked by alias); 21 Dec 2019 17:19:20 -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 55287 invoked by uid 89); 21 Dec 2019 17:19:20 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-lj1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8acvHYr8vRrcP5wX84Rlf220+YSPuAUIyN6hWEPg1t4=; b=ezap9Q4eW5kqQjK/wPuGcPQ0nMgHcfyZIMB6A5oO1i2eRm8KUR06vglNk1r9kLwD83 C8Owmjexix6LznOzPeXx1duFYMpRVMozWFjx0fBcrLK2VZML6Ldg434isqt0rEt9LoU6 ss/Wt6qxspd1fCCIyT28CjqAaFCsOiur57rxUReE7NXyMK3v6FsDH3RTsi/HjvoN+AHJ VGDYLI7FjkOvUk7aU7RM75ZDlAfO3Bl1PtXZlnSEYZcvNC1CehhWOYKteBCM9zNNaK8I 69rmnaO288T6Ff/st9Q2PfsxvvIXEB6h+MAdC/Fx7eQn3SuQHZkfp4bhBjsLpxXOLpsd uhWA== MIME-Version: 1.0 References: In-Reply-To: From: Alistair Francis Date: Sat, 21 Dec 2019 09:18:49 -0800 Message-ID: Subject: Re: 32-bit time_t inside itimerval To: Arnd Bergmann Cc: GNU C Library , Alistair Francis , Lukasz Majewski Content-Type: text/plain; charset="UTF-8" On Sat, Dec 21, 2019 at 5:31 AM Arnd Bergmann wrote: > > On Fri, Dec 20, 2019 at 10:35 PM Alistair Francis wrote: > > > > Hey, > > > > I just noticed something strange. > > > > The setitimer syscall is not different for 32/64-bit time_t. So we use > > this syscall for both 32/64 time_t [1] > > > > SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value, > > struct itimerval __user *, ovalue) > > > > Where struct itimerval __user *, value looks like this [2]: > > > > struct itimerval { > > struct timeval it_interval; /* timer interval */ > > struct timeval it_value; /* current value */ > > }; > > > > Which then uses this structure for timeval [3]: > > > > struct timeval { > > __kernel_old_time_t tv_sec; /* seconds */ > > __kernel_suseconds_t tv_usec; /* microseconds */ > > }; > > > > And __kernel_old_time_t is defined [4] as: > > > > typedef __kernel_long_t __kernel_old_time_t; > > typedef __kernel_long_t __kernel_time_t; > > Right, with my latest patches, this gets changed to __kernel_old_timeval, with > an unmodified definititon. > > > So __kernel_old_time_t and __kernel_time_t are both 32-bit values > > inside the kernel. and the setiimer syscall expects a 32-bit time_t > > for the values inside it. > > > > This is different to the current glibc implementation where all time_t > > values are treated as 64-bit for RISC-V [5]. > > > > What should we do here? > > > > 1. Change glibc to use a 32-bit time_t for some structures, such as > > the timeval inside itimerval? > > 2. Convert the kernel time_t to be 64-bit for RV32? > > What happened here is that originally I thought we would not need > setitimer/getitimer > and could fall back to timer_settime/timer_gettime, but that turned out to be a > misunderstanding (we do need both). > > By the time we introduced all the other system calls with 64-bit > time_t in linux-5.1, > there was no replacement yet, but since these interfaces never pass > absolute times > on the kernel ABI, it was considered good enough. There was a small debate on > whether struct itimerval and struct rusage (which has the same problem) should > have replacements using struct __kernel_timespec, or a newly added > __kernel_timeval, and that discussion never had a conclusion, so we > left it at this. Thanks for clarifying ths Arnd. Ok, I didn't realise this was the case. It ends up being a bit of a pain. > > For glibc, the only sensible implementation is to implement the time64 > settimer/getitimer interfaces on top of the time32 setitimer/getitimer > system calls, > doing the conversion internally. (Same for getrusage and wait4). Ok, so we need to fix setitimer/getitimer, getrusage and waitid's rusage (wait4 isn't in y2038 safe calls). For the glibc people, can we do something like this? 1. Add a __old_timeval struct used by the itimerval and rusage structs 2. Make __old_timeval use __old_time_t that is always a long (no matter what time_t really is) Then the question becomes do we expose __old_timeval (with 32-bit time_t) or the real timeval (64-bit time_t) to callers of the functions? If we are exposing the new one we will have to edit the four functions to convert 32-bit to 64-bit. Which should all be pretty straight forward. If we don't expose the new one it should be even easier. I'm not sure what is more appropriate for glibc, let me know and I should be able to get some patches ready. Maybe this can make it in before freeze :) > > We may still want to introduce getitimer_time64, setiitimer_timer64, > getrusage_time64 and waitid_time64 at some point, using __kernel_timespec > to have a saner user space interface, but there is no real point in glibc > using those syscalls as the underlying implementation when the fallback > to the time32 versions is still required. I would +1 adding getitimer_time64, setiitimer_timer64, getrusage_time64 and waitid_time64 as it simplifies things. Alistair > > Arnd