Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2510215pxb; Tue, 21 Sep 2021 01:10:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzV1N56pIR1vKhZ9O7D2LrLQdI0+kRA9RyNfXlHnmdoZB+WAdmFWyqNADaCxA7OlHS93Mnj X-Received: by 2002:a6b:6610:: with SMTP id a16mr1007255ioc.120.1632211834351; Tue, 21 Sep 2021 01:10:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632211834; cv=none; d=google.com; s=arc-20160816; b=IuGtjMP3dVnpuBtWC8i4ZaA+OSIjJD2noZwoo8W5C7Cesxm9DxYrf/d84oCch4RfYO 5fas/aCszCfxml8QBllNGFkOzxyGdvIxy6Q6xdK69Zzv/QCbMNQFs9D0AxA+THsEcF/q aLhjSv079n5TPbWlRWzg28N8ZabxzClKrWCFHLGn6RME/UzFhl1wUE2LmFRyHpHoSl+9 jYm+tNZj9Rrs2sih7SZcm4tgWNbhHLckPw6GImaO0hjN/3Y0bzqnZWSiGsZVYr4bfzCe GlPgqOBGq4ReS/bXhVTatR0L/bzcvbluzV382SShEEWqWQN7nUalS/LeDL+v4FvgfRQg TeGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=V/rje7SEI+XLGYlJqS0hbr2Hn/XUnM5xLaawWX3MpcU=; b=YJs9mMCf7NFidIWx+Or/DTuW2kAlQHEW3pNFj5S7bO90YGKV/AaPSgnxdRrf7SgH9s XBfl1KI/X/xzg7SpXPU/VE4Wi4KBYcyiIwuvDA8A9hwP1agy8I8/nodZPfaXXqRMxwkn 0xC/hGIAVgNg1Qz78A0m8MAp0OkkxG687L8bMcD93+Afx9RH80uNU0h6RbcaBI6jtZCd BUbtuNnZIhHC02ygOyco+WLAddRlqd/aSFUdxuB4eA58p3n0VrucsBSJ1GGto0tGvvaX o7dm6nwHCO4vwZNBvvesedhRXVuwXxA81Pnm+xA+w8qOPiebVI2bKLk0gK+hLwWnKV0s rhyw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si16328727jar.102.2021.09.21.01.10.22; Tue, 21 Sep 2021 01:10: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230492AbhIUIKJ convert rfc822-to-8bit (ORCPT + 99 others); Tue, 21 Sep 2021 04:10:09 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:52379 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230032AbhIUIKI (ORCPT ); Tue, 21 Sep 2021 04:10:08 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]) by mrelayeu.kundenserver.de (mreue009 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MUok5-1mJcZC1Csb-00QgVF; Tue, 21 Sep 2021 10:08:39 +0200 Received: by mail-wr1-f43.google.com with SMTP id t8so29588364wri.1; Tue, 21 Sep 2021 01:08:39 -0700 (PDT) X-Gm-Message-State: AOAM531O3Bu8Xsc1krB8Y3q5vCx+SAhQZ9GshjuaAeQTTV3sg2nIzC0b IZGqldQ2SKT50mhX7SrmD//2WiH8Ibs8C2qtpf0= X-Received: by 2002:adf:f481:: with SMTP id l1mr2382016wro.411.1632211718939; Tue, 21 Sep 2021 01:08:38 -0700 (PDT) MIME-Version: 1.0 References: <20210917061040.2270822-1-alistair.francis@opensource.wdc.com> <20210917061040.2270822-2-alistair.francis@opensource.wdc.com> <72990864-5ec6-1f73-efd9-61b667a172dd@collabora.com> In-Reply-To: <72990864-5ec6-1f73-efd9-61b667a172dd@collabora.com> From: Arnd Bergmann Date: Tue, 21 Sep 2021 10:08:22 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] perf bench: Add support for 32-bit systems with 64-bit time_t To: =?UTF-8?Q?Andr=C3=A9_Almeida?= 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 , Arnd Bergmann , Alistair Francis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:2yF3PfTcmCw/0IsZGBaRWPlj+IyCqMBI9CMPm79Q8KL/6PWQNo9 Q6LCo0fJITzs+lxJO9kzln0lfLXo0yaCv3Zlm+tHbhZVMYgz+foXCkR89UenROLJ6OuOsZ5 vF+nr+8aYJ6TwO1u+GZQrIPkpUd2ssI1GFxplKeRQrv1vNA3fyuYF61Y5Q/InADiotHilTe 9qhDO+IWqlqcVOiNwU30Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ePN22AnODOg=:cBr3hn4Wi3cbzGIiKUDsZN fwb3KrAmwoPq/FgFsC3UOYZz+EuCUMqMuO5YODB+GZ2fykVq8sBtqtaeeTDsWvyE5R++7ZfNH ZkabrmgHpUEN68Ooo+j3a2XLf13Tvi3ruDc7mbVwkUK+g54xDbQKpLnCG5L+LDP4Vy0on+kB2 kXogpGzWyZaf7sXr/reZr8L3p+YoDKDRnTnKZ/htxqqvnP+QjJ6N9ZN55JkUpvtaVNUpd7RWn imPJa+QArdHl55tH1h1QmW/lztpLbHXGDvUTV57x4/jEX7x/HV8evYIcEaG/6VgtLmUAjI7/F Ze1UrAbbddllgNZ83Nxv6y6cLUGuXkp2ohUT3U6taGFEMdWnGokpA3SGrtoz2bp2bW/v2I8KZ 8KT8Hi5trlkI1EPtaTpxQHm04Gt7smBaC0Vvl9aifjifNUIOXLssXKU2wf+Vld7M8Qc4rlzql 7l/P6fLgRLuz/NvCO/42HVsfnV/A0yC/WVCUyEBSrkJ2WKSbyfETs/vwVUNmPL4eVCfzL2p+u XEgDPc1OwTvrn/NU380AwM8Mj7+EKmFqqGr3l+Fmy75O1kBbjZqzTrVtqSwBWhGva0UoIqAsQ ttr9ynx58EOGa8KvmU6rHY/7t4QPKF18d12Nx50Po9Rmaq6vF6aRMdDmr9hU6ks2gUYp3UhK3 lgS5rnxxdVQB3dfDi4o9pF8HXVafL2RBiRm7mEpEa9MobIdSUSE7xzCeP5R+OBkKhEjUD0Xb4 nEuen2i+YFBw1pSy8aZHF5Bu26ZgtCnePZZHTcmCW2w0YhQhXjBg7K3+nN2A3QmbteqxDKE/A I32UC2mDBSKBggPvYpj7dE/o12s47wsEeS3R8Y6vUugeyhmRJTpe9tHjF1tdJrutvUDy2acgG X+IdfDVN31T5JlMABIfw== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. We normally don't do this in kernel headers, but I think the benefits would be far greater compared to today's situation. Arnd