linux-kernel - Re: [PATCH 16/20] futex: Implement sys_futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a1s=fJPyaCUj0otNA2bWjY09F_ir2zxigFgaZ69ejHkcw@mail.gmail.com>
Date:   Wed, 15 Sep 2021 20:47:51 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     André Almeida <andrealmeid@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Collabora kernel ML <kernel@...labora.com>,
        Gabriel Krisman Bertazi <krisman@...labora.com>,
        Linux API <linux-api@...r.kernel.org>,
        GNU C Library <libc-alpha@...rceware.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 16/20] futex: Implement sys_futex_waitv()

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