From: Peter Zijlstra <peterz@infradead.org>
To: tglx@linutronix.de, axboe@kernel.dk
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net,
andrealmeid@igalia.com, Andrew Morton <akpm@linux-foundation.org>,
urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com,
Arnd Bergmann <arnd@arndb.de>,
linux-api@vger.kernel.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, malteskarupke@web.de
Subject: [RFC][PATCH 00/10] futex: More Futex2 bits
Date: Fri, 14 Jul 2023 15:38:59 +0200 [thread overview]
Message-ID: <20230714133859.305719029@infradead.org> (raw)
Hi,
Reviewing Jens' series to add io_uring futex support got me looking at futex
again, and I realized the current flags situation is a mess. After cleaning
that up I decided to continue and implement most of the missing flags for
futex2.
I initially also wanted to add a futex_wait() syscall, but given the amount and
kind of arguments that needs, that's just not going to work on 32bit.
futex_waitv() will have to do for now.
I've not yet done futex_requeue(), that's even worse than futex_wait() and I
think the only option is to do something like:
sys_futex_requeue(struct futex_waitv __user futexes[2], unsigned int flags, int nr_wake, int nr_requeue)
Where we use struct futex_wativ to specify the two futexes (addr and flags) and
cmp value.
Additionally, robust futexes can fundamentally only support 32bit unless we go
make more lists.
The 'small' futex support is very limited, esp. when combined with FUTEX2_NUMA
mixing sizes is really not an option. The requeue variant above would be able
to specify different sizes for each futex and might just do.
The whole series is *very* lightly tested, as in, it builds and boots, but I've
not yet written a single line of user code to trigger any of the new paths.
Please handle with care etc.. ;-)
Jens, given you do a completely new futex interface, it probably makes more
sense if you use FUTEX2 flags and a u64 value and mask.
I'm hoping this series clarifies that situation a little instead of making it a
worse mess. Many of these things have been brewing over the past several years
but nobody put it all together before.
next reply other threads:[~2023-07-14 14:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 13:38 Peter Zijlstra [this message]
2023-07-14 13:39 ` [RFC][PATCH 01/10] futex: Clarify FUTEX2 flags Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 02/10] futex: Extend the " Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 03/10] futex: Flag conversion Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 04/10] futex: Add sys_futex_wake() Peter Zijlstra
2023-07-14 14:26 ` Arnd Bergmann
2023-07-14 14:47 ` Peter Zijlstra
2023-07-14 20:10 ` Arnd Bergmann
2023-07-14 13:39 ` [RFC][PATCH 05/10] mm: Add vmalloc_huge_node() Peter Zijlstra
2023-07-14 14:37 ` Matthew Wilcox
2023-07-14 15:09 ` Peter Zijlstra
2023-07-14 15:11 ` Matthew Wilcox
2023-07-14 15:26 ` Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 06/10] futex: Propagate flags into get_futex_key() Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 07/10] futex: Implement FUTEX2_NUMA Peter Zijlstra
2023-07-14 15:22 ` Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 08/10] futex: Propagate flags into futex_get_value_locked() Peter Zijlstra
2023-07-14 13:39 ` [RFC][PATCH 09/10] futex: Enable FUTEX2_{8,16} Peter Zijlstra
2023-07-14 13:39 ` [HACK][PATCH 10/10] futex: Munge size and numa into the legacy interface Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230714133859.305719029@infradead.org \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=hch@infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=malteskarupke@web.de \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox