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,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,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 893B51F463 for ; Sat, 21 Dec 2019 13:31:41 +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=jByT qQwoLSA0V8YExfAAAV+u6QsC98M5q2EXzWbkDNYJ8LZWnCMoxSAQAzXSoxECeG2Z uJ5kZZIN0Ld9B2JPIxNeL9tWW9P6QfjCa0pqmOutqoOvLvW/xD7cS1w+7Oawew31 BA2Z14uNtiS+qOOtEY3ztFg7znOL4e8b0d84mZ4= 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=fdKQOuMDYQ h/qXSIiF4GryNou8M=; b=jkwIxBosTOGvKDuCsZ0INHY/iVQ26LXKAdRDqCgNoH mAUzO6ZvswXQTRUwjJvGBmuttZbk3NwkcuZgMhIC8RaTwvveCokUykKIAUYcoExh TU2tIzyEKhmp50E+LxT53Y0+aU6qcMaDGYdaic/w8VLo/eE+QSb2a78/okhNwIUB U= Received: (qmail 1545 invoked by alias); 21 Dec 2019 13:31:39 -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 1536 invoked by uid 89); 21 Dec 2019 13:31:38 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mout.kundenserver.de MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Sat, 21 Dec 2019 13:31:16 +0000 Message-ID: Subject: Re: 32-bit time_t inside itimerval To: Alistair Francis Cc: GNU C Library , Alistair Francis , Lukasz Majewski Content-Type: text/plain; charset="UTF-8" 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. 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). 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. Arnd