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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 099C81F8C6 for ; Wed, 15 Sep 2021 18:48:42 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 38B303857832 for ; Wed, 15 Sep 2021 18:48:40 +0000 (GMT) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by sourceware.org (Postfix) with ESMTPS id 3EA053857C6B for ; Wed, 15 Sep 2021 18:48:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EA053857C6B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=arndb.de Received: from mail-wr1-f41.google.com ([209.85.221.41]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Msqpq-1mkZfs04BE-00tB3z for ; Wed, 15 Sep 2021 20:48:08 +0200 Received: by mail-wr1-f41.google.com with SMTP id m9so5468180wrb.1 for ; Wed, 15 Sep 2021 11:48:07 -0700 (PDT) X-Gm-Message-State: AOAM530oXD/0wnFrmWWW2G99NRiZo1gD/upYx2EMbDVvxC+Rm9Jb91jr em7KONzZXU/ePfY7DUJ8kIk8yyw4feq4ivwA3q8= X-Google-Smtp-Source: ABdhPJxK7SeTGX8+XfGCJ4SbF2UTweNhxicgClsiVZ2HPcmo85hjrsvQk6FDN6pdsJWlaTcZb9qud2EO6qBml0363OE= X-Received: by 2002:adf:f884:: with SMTP id u4mr1571436wrp.411.1631731687472; Wed, 15 Sep 2021 11:48:07 -0700 (PDT) MIME-Version: 1.0 References: <20210915140710.596174479@infradead.org> <20210915141525.621568509@infradead.org> In-Reply-To: From: Arnd Bergmann Date: Wed, 15 Sep 2021 20:47:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 16/20] futex: Implement sys_futex_waitv() To: Peter Zijlstra Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:sFBnu6movzviCXF6Qr/OAezBTVqn1nF4OMYITb1nzoSOj2nMj5L MTkEmI+nU42CS0CBGd262EnQw8ahtBQHewqVHI75W0xcm3LO7CLJsGm14mSaB3oaN/+4pY0 Sam3SBztHSalEe5fYWtBz/5JVWYUyqr8NLOm+ByQgCCtJ4n0RM+1VgLVldcglJ5ZTgV5CLc /kv6YWbVtKw2Ce06MYz4w== X-UI-Out-Filterresults: notjunk:1;V03:K0:GB7+sC7eNKw=:RzCMSNvpEAxGEUV++4mq/R 7Ic4wCB7N4xNGXK/pm5WjTaZBLmxJJ30MikAyKhtsBQ6GBInmEQ+kop/hHGLH1K4LhS0l/iQC EYtZ8LvoNh7FrqdVJokV+oMUO1wUuJabRkIQeM3HAFiO9uKoqTLM0bUmaqIPFFgJkKVuJdvY2 7m/VSWxh50lD/GpMlNbojz/YfwTsiuMY5QIOK9yiphAGZrEo3R6IsPJyHGe9Y+Oo5WsJ7/7rb 6R7J/+eHYbUkbGHD0g2jI+bBxfNhomRIEv/Q9l1+nRnuAWNM3rcTpN3GA4ZxEXv6kJMc8oZxa dG28hSOhwHgkzmVyOUrwaxrHC0pKHfGPaAQB/H6Ytivbxez9xKQFXahVvVstMQ4VTa/27kKYR JuiUdazQZBkspDNs/Cw048NzvFo9/goh74ReTBSJu0lPh7HmyHUCwoNlZbiP9vEdQhrj+c5KJ fwKr/Q10bo+1Q+JLeuXVViwCxo0s5s1B2aR/gzD2jO3DLQugrra8iAlBg77DQ7dlvDSFRpmGi 1BibgBkhzcFj+h7M3nRazTuZT/pRrxN5qOzU66cRkeUo+ruYBYKbxuv+IwuToZbCeYNGXnij7 mTNx3EFiF0qbJDrJjjBKXHT1Sc/ood82k2FPBUjZm6DtZc+8spYy+f2nqKgPW0YnfdmfjE+0Z l5fmL1/TU9FsEITpuEYgdXddKEDKpGl5wptuSzAz5SirPE/lFTfvhVgB1K92MVeAiqTRkZGtg hT+hMubwxyWVncjrrYtNh4nFJCwS8ko0pxtS2w== 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: , Cc: Davidlohr Bueso , GNU C Library , Linux API , Sebastian Andrzej Siewior , Linux Kernel Mailing List , Steven Rostedt , Ingo Molnar , Michael Kerrisk , =?UTF-8?Q?Andr=C3=A9_Almeida?= , Darren Hart , Thomas Gleixner , Collabora kernel ML , Gabriel Krisman Bertazi Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Wed, Sep 15, 2021 at 5:39 PM Peter Zijlstra wrote: > > On Wed, Sep 15, 2021 at 04:07:26PM +0200, Peter Zijlstra wrote: > > +SYSCALL_DEFINE4(futex_waitv, struct futex_waitv __user *, waiters, > > + unsigned int, nr_futexes, unsigned int, flags, > > + struct __kernel_timespec __user *, timo) > > So I utterly detest timespec.. it makes no sense what so ever. > > Can't we just, for new syscalls, simply use a s64 nsec argument and call > it a day? > > Thomas, Arnd ? Do you mean passing the nanoseconds by value instead of a pointer? I think that would be worse, since that means having incompatible calling conventions between 32-bit and 64-bit architectures, and even between 32-bit architectures that have different requirements for 64-bit function arguments. If we pass it by reference, there is much less to gain from changing the timespec to plain nanoseconds. I wouldn't object to that, but I don't see it helping much either. It would work for relative timeouts, but the general trend seems to be to specify timeouts as absolute times, and that would force each caller to read the time using clock_gettime() and then convert it to nanoseconds before adding the timeout. Specifying the timeout in terms of 32-bit relative milliseconds would the way that epoll() does would be really simple, but that still feels odd. Arnd