Message ID | 20200709175921.211387-1-andrealmeid@collabora.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 339EF3844047; Thu, 9 Jul 2020 18:00:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 339EF3844047 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1594317643; bh=jUU9tLahOnn2jlPUVirsWDsFOjCgx+5Jhyr9qe46uJg=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=u20idN4h/h2CCdQBLtY/nJXBs1g8gIu9jQ/XKS6AQwcGReGM/KU+yNvd2iP+bYWhl 0+J3osXx9YGivxobRg79KOSF3lH0Hl9QvDgF7Li/6oDhGdrV6grufz4f1DuJWBJWYN q73aYx8VmjN8kWBRsonnrSvCJ+g96fFfInxLtNzg= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by sourceware.org (Postfix) with ESMTPS id 598EA3861970 for <libc-alpha@sourceware.org>; Thu, 9 Jul 2020 18:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 598EA3861970 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id C5E122A65E7 To: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org Subject: [RFC v2 0/4] futex2: Add new futex interface Date: Thu, 9 Jul 2020 14:59:17 -0300 Message-Id: <20200709175921.211387-1-andrealmeid@collabora.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: =?utf-8?q?Andr=C3=A9_Almeida_via_Libc-alpha?= <libc-alpha@sourceware.org> Reply-To: =?utf-8?q?Andr=C3=A9_Almeida?= <andrealmeid@collabora.com> Cc: fweimer@redhat.com, malteskarupke@web.de, libc-alpha@sourceware.org, linux-api@vger.kernel.org, mingo@redhat.com, andrealmeid@collabora.com, dvhart@infradead.org, kernel@collabora.com, krisman@collabora.com, pgriffais@valvesoftware.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series | futex2: Add new futex interface | |
Message
André Almeida
July 9, 2020, 5:59 p.m. UTC
Hello, This RFC is a followup to the previous discussion initiated from my last patch "futex: Implement mechanism to wait on any of several futexes"[1]. As stated in the thread, the correct approach to move forward with the wait multiple operation would be to create a new syscall that would have all new cool features. The first patch adds the new interface and just translate the call for the old interface, without implementing new features. The goal here is to establish the interface and to check if everyone is happy with this API. The rest of patches are selftests to show the interface in action. I have the following questions: - What suggestions do you have to implement this? Start from scratch or reuse the most code possible? - The interface seems correct and implements the requirements asked by you? Those are the cool new features that this syscall should address some day: - Operate with variable bit size futexes, not restricted to 32: 8, 16 and 64 - Wait on multiple futexes, using the following semantics: struct futex_wait { void *uaddr; unsigned long val; unsigned long flags; }; sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters, unsigned long flags, struct __kernel_timespec *timo); - Have NUMA optimizations: if FUTEX_NUMA_FLAG is set, the `void *uaddr` argument won't be a value of type u{8, 16, 32, 64} anymore, but a struct containing a NUMA node hint: struct futex32_numa { u32 value __attribute__ ((aligned (8))); u32 hint; }; struct futex64_numa { u64 value __attribute__ ((aligned (16))); u64 hint; }; Thanks, André Changes since v1: - The timeout argument now uses __kernel_timespec as type - time32 interface was removed v1: https://lore.kernel.org/patchwork/cover/1255437/ [1] https://lore.kernel.org/patchwork/patch/1194339/ André Almeida (4): futex2: Add new futex interface selftests: futex: Add futex2 wake/wait test selftests: futex: Add futex2 timeout test selftests: futex: Add futex2 wouldblock test MAINTAINERS | 2 +- arch/x86/entry/syscalls/syscall_32.tbl | 2 + arch/x86/entry/syscalls/syscall_64.tbl | 2 + include/linux/syscalls.h | 7 ++ include/uapi/asm-generic/unistd.h | 8 +- include/uapi/linux/futex.h | 10 ++ init/Kconfig | 7 ++ kernel/Makefile | 1 + kernel/futex2.c | 73 ++++++++++++ kernel/sys_ni.c | 4 + tools/include/uapi/asm-generic/unistd.h | 7 +- .../selftests/futex/functional/.gitignore | 1 + .../selftests/futex/functional/Makefile | 4 +- .../selftests/futex/functional/futex2_wait.c | 111 ++++++++++++++++++ .../futex/functional/futex_wait_timeout.c | 38 ++++-- .../futex/functional/futex_wait_wouldblock.c | 33 +++++- .../testing/selftests/futex/functional/run.sh | 3 + .../selftests/futex/include/futex2test.h | 77 ++++++++++++ 18 files changed, 373 insertions(+), 17 deletions(-) create mode 100644 kernel/futex2.c create mode 100644 tools/testing/selftests/futex/functional/futex2_wait.c create mode 100644 tools/testing/selftests/futex/include/futex2test.h
Comments
Hello. On 09.07.2020 19:59, André Almeida wrote: > This RFC is a followup to the previous discussion initiated from my > last > patch "futex: Implement mechanism to wait on any of several > futexes"[1]. > As stated in the thread, the correct approach to move forward with the > wait multiple operation would be to create a new syscall that would > have > all new cool features. > > The first patch adds the new interface and just translate the call for > the old interface, without implementing new features. The goal here is > to establish the interface and to check if everyone is happy with this > API. The rest of patches are selftests to show the interface in action. > I have the following questions: > > - What suggestions do you have to implement this? Start from scratch or > reuse the most code possible? > > - The interface seems correct and implements the requirements asked by > you? > > Those are the cool new features that this syscall should address some > day: > > - Operate with variable bit size futexes, not restricted to 32: > 8, 16 and 64 > > - Wait on multiple futexes, using the following semantics: > > struct futex_wait { > void *uaddr; > unsigned long val; > unsigned long flags; > }; > > sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters, > unsigned long flags, struct __kernel_timespec *timo); > > - Have NUMA optimizations: if FUTEX_NUMA_FLAG is set, the `void *uaddr` > argument won't be a value of type u{8, 16, 32, 64} anymore, but a > struct > containing a NUMA node hint: > > struct futex32_numa { > u32 value __attribute__ ((aligned (8))); > u32 hint; > }; > > struct futex64_numa { > u64 value __attribute__ ((aligned (16))); > u64 hint; > }; > > Thanks, > André > > Changes since v1: > - The timeout argument now uses __kernel_timespec as type > - time32 interface was removed > v1: https://lore.kernel.org/patchwork/cover/1255437/ > > [1] https://lore.kernel.org/patchwork/patch/1194339/ > > André Almeida (4): > futex2: Add new futex interface > selftests: futex: Add futex2 wake/wait test > selftests: futex: Add futex2 timeout test > selftests: futex: Add futex2 wouldblock test > > MAINTAINERS | 2 +- > arch/x86/entry/syscalls/syscall_32.tbl | 2 + > arch/x86/entry/syscalls/syscall_64.tbl | 2 + > include/linux/syscalls.h | 7 ++ > include/uapi/asm-generic/unistd.h | 8 +- > include/uapi/linux/futex.h | 10 ++ > init/Kconfig | 7 ++ > kernel/Makefile | 1 + > kernel/futex2.c | 73 ++++++++++++ > kernel/sys_ni.c | 4 + > tools/include/uapi/asm-generic/unistd.h | 7 +- > .../selftests/futex/functional/.gitignore | 1 + > .../selftests/futex/functional/Makefile | 4 +- > .../selftests/futex/functional/futex2_wait.c | 111 ++++++++++++++++++ > .../futex/functional/futex_wait_timeout.c | 38 ++++-- > .../futex/functional/futex_wait_wouldblock.c | 33 +++++- > .../testing/selftests/futex/functional/run.sh | 3 + > .../selftests/futex/include/futex2test.h | 77 ++++++++++++ > 18 files changed, 373 insertions(+), 17 deletions(-) > create mode 100644 kernel/futex2.c > create mode 100644 > tools/testing/selftests/futex/functional/futex2_wait.c > create mode 100644 tools/testing/selftests/futex/include/futex2test.h What branch/tag this submission is based on please? It seems it is not a 5.8 but rather 5.7 since the second patch misses faccessat2() syscall and fails to be applied cleanly. Thanks.
Hi On 7/10/20 10:23 AM, Oleksandr Natalenko wrote: > Hello. > > On 09.07.2020 19:59, André Almeida wrote: >> This RFC is a followup to the previous discussion initiated from my last >> patch "futex: Implement mechanism to wait on any of several futexes"[1]. >> As stated in the thread, the correct approach to move forward with the >> wait multiple operation would be to create a new syscall that would have >> all new cool features. >> >> The first patch adds the new interface and just translate the call for >> the old interface, without implementing new features. The goal here is >> to establish the interface and to check if everyone is happy with this >> API. The rest of patches are selftests to show the interface in action. >> I have the following questions: >> >> - What suggestions do you have to implement this? Start from scratch or >> reuse the most code possible? >> >> - The interface seems correct and implements the requirements asked by >> you? >> >> Those are the cool new features that this syscall should address some >> day: >> >> - Operate with variable bit size futexes, not restricted to 32: >> 8, 16 and 64 >> >> - Wait on multiple futexes, using the following semantics: >> >> struct futex_wait { >> void *uaddr; >> unsigned long val; >> unsigned long flags; >> }; >> >> sys_futex_waitv(struct futex_wait *waiters, unsigned int nr_waiters, >> unsigned long flags, struct __kernel_timespec *timo); >> >> - Have NUMA optimizations: if FUTEX_NUMA_FLAG is set, the `void *uaddr` >> argument won't be a value of type u{8, 16, 32, 64} anymore, but a >> struct >> containing a NUMA node hint: >> >> struct futex32_numa { >> u32 value __attribute__ ((aligned (8))); >> u32 hint; >> }; >> >> struct futex64_numa { >> u64 value __attribute__ ((aligned (16))); >> u64 hint; >> }; >> >> Thanks, >> André >> >> Changes since v1: >> - The timeout argument now uses __kernel_timespec as type >> - time32 interface was removed >> v1: https://lore.kernel.org/patchwork/cover/1255437/ >> >> [1] https://lore.kernel.org/patchwork/patch/1194339/ >> >> André Almeida (4): >> futex2: Add new futex interface >> selftests: futex: Add futex2 wake/wait test >> selftests: futex: Add futex2 timeout test >> selftests: futex: Add futex2 wouldblock test >> >> MAINTAINERS | 2 +- >> arch/x86/entry/syscalls/syscall_32.tbl | 2 + >> arch/x86/entry/syscalls/syscall_64.tbl | 2 + >> include/linux/syscalls.h | 7 ++ >> include/uapi/asm-generic/unistd.h | 8 +- >> include/uapi/linux/futex.h | 10 ++ >> init/Kconfig | 7 ++ >> kernel/Makefile | 1 + >> kernel/futex2.c | 73 ++++++++++++ >> kernel/sys_ni.c | 4 + >> tools/include/uapi/asm-generic/unistd.h | 7 +- >> .../selftests/futex/functional/.gitignore | 1 + >> .../selftests/futex/functional/Makefile | 4 +- >> .../selftests/futex/functional/futex2_wait.c | 111 ++++++++++++++++++ >> .../futex/functional/futex_wait_timeout.c | 38 ++++-- >> .../futex/functional/futex_wait_wouldblock.c | 33 +++++- >> .../testing/selftests/futex/functional/run.sh | 3 + >> .../selftests/futex/include/futex2test.h | 77 ++++++++++++ >> 18 files changed, 373 insertions(+), 17 deletions(-) >> create mode 100644 kernel/futex2.c >> create mode 100644 >> tools/testing/selftests/futex/functional/futex2_wait.c >> create mode 100644 tools/testing/selftests/futex/include/futex2test.h > > What branch/tag this submission is based on please? It seems it is not a > 5.8 but rather 5.7 since the second patch misses faccessat2() syscall > and fails to be applied cleanly. > As stated in MAINTAINERS[1], this submission is based on locking/core branch from tip/tip[2] tree. The most updated release tag in this tree is v5.8-rc1. My patches applied on top of locking/core are available in my tree: https://gitlab.collabora.com/tonyk/linux/-/commits/futex2 According to 6c3c184fc420 ("tools headers API: Update faccessat2 affected files"), it seems that `faccessat2` entry at `tools/include/uapi/asm-generic/unistd.h` was added after the syscall was merged, so that's why 5.8-rc1 misses the syscall in this specific file. Rebasing locking/core in 5.8-rc2 or above will fix that. > Thanks. > Thanks, André [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v5.8-rc4#n7102 [2] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=locking/core