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;
MIME-Version: 1.0
References: <20210915140710.596174479@infradead.org> <20210915141525.621568509@infradead.org>
 <YUITUXbnzAK98DEl@hirez.programming.kicks-ass.net>
In-Reply-To: <YUITUXbnzAK98DEl@hirez.programming.kicks-ass.net>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 15 Sep 2021 20:47:51 +0200
Message-ID: <CAK8P3a1s=fJPyaCUj0otNA2bWjY09F_ir2zxigFgaZ69ejHkcw@mail.gmail.com>
Subject: Re: [PATCH 16/20] futex: Implement sys_futex_waitv()
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     =?UTF-8?Q?Andr=C3=A9_Almeida?= <andrealmeid@collabora.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Darren Hart <dvhart@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Collabora kernel ML <kernel@collabora.com>,
        Gabriel Krisman Bertazi <krisman@collabora.com>,
        Linux API <linux-api@vger.kernel.org>,
        GNU C Library <libc-alpha@sourceware.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Arnd Bergmann <arnd@arndb.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Sep 15, 2021 at 5:39 PM Peter Zijlstra <peterz@infradead.org> 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