From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id F1F10385C40F for ; Sat, 10 Jul 2021 19:57:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1F10385C40F Received: by mail-pf1-x430.google.com with SMTP id j199so12164675pfd.7 for ; Sat, 10 Jul 2021 12:57:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XGPD8Vzir3u1JQl6qVKpMB0PCfMXBaXnI88Ci+FvsTg=; b=XuwtNvZtb1sRA5e+jwYsROaTSblMJm4E2qpxzgEV6CVy6kdcH+oduXcfSnVxpL8m45 st92tM2Q7vbMeJI2oSBs/C613xMi6203nFN5axB61mPKlWV9yka+/DFE033pbW5Gfywr lph3P4P7gZuZriOkF3h/OAfbz4P4pBiozw6+xaprNeJOTD+BHmnZrmttDtJmCBnOTbj0 83Tez8UuM3Fl4FfLZmpNkDI6IIaHc60e3+JzIumu60ZamvVhbGXGaZoEpA8VU6U6dlel bUafK0tNk1E5rTo23kS3nMSuZsRRbzuLw6nZ161du6tI2inwDGiUmzCWRcplYrqDL7Iu QPSw== X-Gm-Message-State: AOAM533W5YUCZkgaY+pgp69/53ePoWiXEjm+isGKuyxmV2G6qwWwZ3qA D9dBGG+Nr1+z93/G84CUKGMlPc1eHRsRXQ== X-Google-Smtp-Source: ABdhPJzrETIfWfhB5Xkw/bsfjFSNXbnK+PEyY22sSrG2858yqLGftDhAd83CZaFg2WxnawBRmATVvg== X-Received: by 2002:a63:b25c:: with SMTP id t28mr45514811pgo.251.1625947075885; Sat, 10 Jul 2021 12:57:55 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id m13sm10040940pfo.102.2021.07.10.12.57.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Jul 2021 12:57:55 -0700 (PDT) Subject: Re: [PATCH] Linux: Use 32-bit vDSO for clock_gettime, gettimeofday, time (bug 28071) To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87czrqf5un.fsf@oldenburg.str.redhat.com> <878s2ef19p.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Sat, 10 Jul 2021 16:57:53 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <878s2ef19p.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 19:57:58 -0000 On 10/07/2021 15:54, Florian Weimer wrote: > * Adhemerval Zanella: > >> This does not fix the issue for __ASSUME_TIME64_SYSCALLS where it still uses >> INLINE_SYSCALL_CALL which might clobber the errno, besides adding another >> ifdef code path (which I really want to avoid). Instead I think we need to >> open-coded the INLINE_VSYSCALL macro and replace all INLINE_SYSCALL_CALL >> with INTERNAL_SYSCALL_CALLS: > > But for __ASSUME_TIME64_SYSCALLS, clock_gettime64 will not fail. > > What am I missing? Is the issue that INLINE_VSYSCALL may set ENOSYS > artificially? I meant for __clock_gettime64, where it may still clobber the errno on older kernels (although it might be a fringe case). In any case, I still think making all time32 call to call time64 is a better implementation than add some specific calls for time32.