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 6613B1F463 for ; Thu, 2 Jan 2020 12:28:45 +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=GlEJ I8puBJaKiZhHBCBOUvgjgsbMBb3yU+kUnZTbnhLuvNUA0VrIGZLy0CntEi+p3vxa MKt4mEHnlOmoxdOJBgo5AlR+Ge99nres8QfVVbON+L3YveGxHYP29Ik+5kKLkqND o6lKsBqj6s97Qh1+rUykpdqfyM6f39thg33wjjo= 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=mpY/wp9k+B z6vJyyNvnAMX1HiBo=; b=UMTfhtG35DL4o6vhloMJFqeR3SwKlyOR07Xyw8tHSI aG/EyOZuTUtqqbJx7C3rNsm2abvA4wlN4GOXpJ2NDRh2nxr9odT6c68NRq7qGxCn t3Vb1PLFOk3+BoT/uF5yqYDuMWQ7Pvmyhv9Xj9tI3pdzezmlH4NTYPlSxW5NsjWG g= Received: (qmail 112009 invoked by alias); 2 Jan 2020 12:28:42 -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 112001 invoked by uid 89); 2 Jan 2020 12:28:42 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mout.kundenserver.de MIME-Version: 1.0 References: <20200102130836.77dfed5e@jawa> In-Reply-To: <20200102130836.77dfed5e@jawa> From: Arnd Bergmann Date: Thu, 2 Jan 2020 13:28:20 +0100 Message-ID: Subject: Re: 32-bit time_t inside itimerval To: Lukasz Majewski Cc: Alistair Francis , GNU C Library , Alistair Francis Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 1:08 PM Lukasz Majewski wrote: > > On Mon, Dec 30, 2019 at 10:22 PM Alistair Francis > > wrote: > > > On Mon, Dec 30, 2019 at 12:11 PM Arnd Bergmann wrote: > > I don't think it's > > fundamentally different from the other system calls that he has > > converted already to work with time64 callers. > > I'm not aware of any RV32 specifics, but it seems to me that it would > be appropriate to use the 64 bit version of struct __itimerspec64 in > glibc - as for example in the conversion patch from [1]. What I mean is that rv32 otherwise does not convert between time32 and time64 interfaces because it always uses the time64 version, so unlike the others, there is probably no helper to convert between the timeval formats either. > As it was already mentioned - those calls set the time to be > decremented and do not operate on "absolute" time values. > Hence, I think that it would be good enough (for now?) to use 32 bit > API wrapped into 64 bit internal glibc values and just return errors > when somebody wants to set timer relative expiration time to overflow > time_t on 32 bit archs (arm,rv32). Yes, that's the idea. The kernel already limits the range to 64-bit nanoseconds because of its timer implementation, so truncating it to 32-bit seconds does not change the behavior either. > Arnd, am I correct that the struct itimerval to __kernel_old_itimerval > conversion patch can be found here [2]? Yes, that's right. This patch only changes the in-kernel implementation as a step to removing the timeval definition from the kernel's uapi headers, it does not change the behavior at all. Arnd