From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DB34C433E0 for ; Thu, 25 Jun 2020 14:38:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E425D2076E for ; Thu, 25 Jun 2020 14:38:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405367AbgFYOil (ORCPT ); Thu, 25 Jun 2020 10:38:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405340AbgFYOik (ORCPT ); Thu, 25 Jun 2020 10:38:40 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7750C08C5C1; Thu, 25 Jun 2020 07:38:39 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id 8A9472A557F Subject: Re: [RFC 0/4] futex2: Add new futex interface To: Arnd Bergmann Cc: "linux-kernel@vger.kernel.org" , Thomas Gleixner , Peter Zijlstra , krisman@collabora.com, Collabora kernel ML , Darren Hart , Ingo Molnar , pgriffais@valvesoftware.com, Florian Weimer , GNU C Library , malteskarupke@web.de, Linux API References: <20200612185122.327860-1-andrealmeid@collabora.com> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= Message-ID: <475e8c39-7d11-f80b-3b4a-e51be5d0963d@collabora.com> Date: Thu, 25 Jun 2020 11:38:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org Hello Arnd, On 6/25/20 3:48 AM, Arnd Bergmann wrote: > On Fri, Jun 12, 2020 at 8:51 PM André Almeida 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. > Thanks for the input. As stated by tglx at [1], "supporting relative timeouts is wrong to begin with", my next patch will use "struct __kernel_timespec *timeout" for an absolute timeout. >> - 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. > Cool, this will make the code cleaner. > Arnd > Thanks, André [1] https://lkml.org/lkml/2019/7/31/1499