Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp70562pxb; Tue, 21 Sep 2021 19:03:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzub/Oez308MDe7kBbp5M/j0FGjsYH9YFxwEQHu/usW5E6OVbHEE0gUYC7OPuSmE4fEFSGQ X-Received: by 2002:a05:6e02:1be6:: with SMTP id y6mr24448988ilv.106.1632276214339; Tue, 21 Sep 2021 19:03:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632276214; cv=none; d=google.com; s=arc-20160816; b=WdJc1VVnTMYxsP5sWWRn28T0EFCyJFJuR9vlmrXORVKA8eCLsGIpk6uw5hUbI88hAH bq92Xlxo8zi/+iaAzu60LHvAgoiJH51Q5hWUCUZ+qtRZZJsmKh5SDMrVknvlq9qhkNRi 1DTS7A+1VoXUVRvcDlDiJSdMNIiB1YlqdKOxzVpvj2hS2n/AsVMQgfwoVVbIUMflfm62 cIEgYQIrBznDu3V7ySjBJhNdor7chpdwvN0dSWd8mvi7mkD/1jJkmd7MANKwB3OZ9T7d FFdplSNwFWJkI2+7fFt1Cs1y7EbEz59KVzySPTfLxwGHKOo/U3rUqT+RQJnFjiMGbyfk XxtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=soT4utEjqxfKzgBSECYqC2yWMxCGpqwOE05Ru8/PegU=; b=n6thGoMVbhKPPfFvTGL9uZdx+uEyS6XL/fB4xa4cxrZMSmesidnE4q1P3j+4oXUVBU yA2/SIRCtKQAiQTNLdB3M44cWwgAUFWF3txKtsZS83K9a8p3s0c5LUam4oMTQKhcjwC+ JjnFZZINgyfCvc/QFtlpzeJAnTK2xAe8SmblLDiBjMRMPRIbx7oi45ABnpPjC3wVX6/j ftxEUc7En/trhMHLq+kN7PFwpubllK+TgKkazHVaf3iy4pLzzs3/guVYIpSJpw58Ho95 uPhj4QcaEhFWiOU5Ahesi3lHG8k5ume/dFsjjM2AFYIItDIeQrOc9OIsJW+y4C5f9vAZ f8Uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o3si966004ilk.61.2021.09.21.19.03.22; Tue, 21 Sep 2021 19:03:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229649AbhIUXID (ORCPT + 99 others); Tue, 21 Sep 2021 19:08:03 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:52752 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhIUXIC (ORCPT ); Tue, 21 Sep 2021 19:08:02 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id 00F781F4358B Message-ID: <9db8c79a-f704-84ce-360b-84335f926a48@collabora.com> Date: Tue, 21 Sep 2021 20:06:21 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH v3 2/2] perf bench: Add support for 32-bit systems with 64-bit time_t Content-Language: en-US To: Arnd Bergmann Cc: Alistair Francis , Linux Kernel Mailing List , Alistair Francis , linux-riscv , Namhyung Kim , Jiri Olsa , linux-perf-users@vger.kernel.org, Alexander Shishkin , Mark Rutland , Arnaldo Carvalho de Melo , Davidlohr Bueso , Darren Hart , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Atish Patra , Alistair Francis References: <20210917061040.2270822-1-alistair.francis@opensource.wdc.com> <20210917061040.2270822-2-alistair.francis@opensource.wdc.com> <72990864-5ec6-1f73-efd9-61b667a172dd@collabora.com> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Às 05:08 de 21/09/21, Arnd Bergmann escreveu: > On Tue, Sep 21, 2021 at 12:47 AM André Almeida > wrote: >> >> #if defined(__i386__) || __TIMESIZE == 32 >> # define NR_gettime64 __NR_clock_gettime64 >> #else >> # define NR_gettime64 __NR_clock_gettime >> #endif >> >> struct timespec64 { >> long long tv_sec; /* seconds */ >> long long tv_nsec; /* nanoseconds */ >> }; >> >> int gettime64(clock_t clockid, struct timespec64 *tv) >> { >> return syscall(NR_gettime64, clockid, tv); >> } >> >> Then we can just use &timeout at __NR_futex_time64 for 32bit arch and at >> __NR_futex for 64bit arch. > > This is still broken when you disable CONFIG_COMPAT_32BIT_TIME, > which disables all system calls that take time32 arguments. > Oh, I think my point was confusing then. My suggestion was to use only the futex entry points that accepts time64, and to always use clock_gettime that uses time64, for all platforms. Then it will work if we disable CONFIG_COMPAT_32BIT_TIME. >> This might be a simpler solution to the problem that you are facing but >> I'm not entirely sure. Also, futex's selftests do use the timeout >> argument and I think that they also won't compile in 32-bit RISC-V, so >> maybe we can start from there so we can actually test the timeout >> argument and check if it's working. > > I would love to see the wrapper that Alistair wrote as part of some kernel > uapi header provided to user space. futex is used by tons of applications, > and we never had a library abstraction for it, so everyone has to do these > by hand, and they all get them slightly wrong in different ways. Why we don't have a futex() wrapper at glibc as we do have for others syscalls? > > We normally don't do this in kernel headers, but I think the benefits > would be far greater compared to today's situation. > > Arnd >