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: <20200612185122.327860-1-andrealmeid@collabora.com>
In-Reply-To: <20200612185122.327860-1-andrealmeid@collabora.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 25 Jun 2020 08:48:29 +0200
Message-ID: <CAK8P3a1fwYX-S84ukxEWBt_DZ09MdBLbQyf4Jgrr-AeqG89jeA@mail.gmail.com>
Subject: Re: [RFC 0/4] futex2: Add new futex interface
To:     =?UTF-8?Q?Andr=C3=A9_Almeida?= <andrealmeid@collabora.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>, krisman@collabora.com,
        Collabora kernel ML <kernel@collabora.com>,
        Darren Hart <dvhart@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, pgriffais@valvesoftware.com,
        Florian Weimer <fweimer@redhat.com>,
        GNU C Library <libc-alpha@sourceware.org>,
        malteskarupke@web.de, Linux API <linux-api@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 12, 2020 at 8:51 PM André Almeida <andrealmeid@collabora.com> wrote:

> - The proposed interface uses ktime_t type for absolute timeout, and I
>   assumed that it should use values in a nsec resolution. If this is true,
>   we have some problems with i386 ABI, please check out the
>   COMPAT_32BIT_TIME implementation in patch 1 for more details. I
>   haven't added a time64 implementation yet, until this is clarified.

ktime_t is not part of the uapi headers, and has always been considered
an implementation detail of the kernel so far. I would argue it should
stay that way. The most sensible alternatives would be to either use
a "__u64 *timeout" argument for a relative timeout, or a
"struct __kernel_timespec *timeout" for an absolute timeout.

old_time32_t also makes no sense for multiple reasons:

- It's another kernel internal type and not part of the uapi headers
- your time32 call has different calling conventions from your time64
  version, not just a different type.
- there should be no need to add syscalls that are known to be buggy
  when there is a replacement type that does not have that bug.

> - Is expected to have a x32 ABI implementation as well? In the case of
>   wait and wake, we could use the same as x86_64 ABI. However, for the
>   waitv (aka wait on multiple futexes) we would need a proper x32 entry
>   since we are dealing with 32bit pointers.

For new syscalls, I'd actually recommend not having a separate
entry point, but just checking 'if (in_compat_syscall())' inside of the
implementation to pick one behavior vs the other when accessing
the user pointers. This keeps the implementation simpler and
avoids assigning a new x32 syscall number that would be different
from all the other architectures.

      Arnd