* [PATCHSET v4] Add io_uring futex/futexv support
@ 2023-07-28 16:42 Jens Axboe
2023-07-28 16:42 ` [PATCH 01/12] futex: Clarify FUTEX2 flags Jens Axboe
` (12 more replies)
0 siblings, 13 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx
s patchset adds support for first futex wake and wait, and then
futexv.
For both wait/wake/waitv, we support the bitset variant, as the
"normal" variants can be easily implemented on top of that.
PI and requeue are not supported through io_uring, just the above
mentioned parts. This may change in the future, but in the spirit
of keeping this small (and based on what people have been asking for),
this is what we currently have.
When I did these patches, I forgot that Pavel had previously posted a
futex variant for io_uring. The major thing that had been holding me
back from people asking about futexes and io_uring, is that I wanted
to do this what I consider the right way - no usage of io-wq or thread
offload, an actually async implementation that is efficient to use
and don't rely on a blocking thread for futex wait/waitv. This is what
this patchset attempts to do, while being minimally invasive on the
futex side. I believe the diffstat reflects that.
As far as I can recall, the first request for futex support with
io_uring came from Andres Freund, working on postgres. His aio rework
of postgres was one of the early adopters of io_uring, and futex
support was a natural extension for that. This is relevant from both
a usability point of view, as well as for effiency and performance.
In Andres's words, for the former:
"Futex wait support in io_uring makes it a lot easier to avoid deadlocks
in concurrent programs that have their own buffer pool: Obviously pages in
the application buffer pool have to be locked during IO. If the initiator
of IO A needs to wait for a held lock B, the holder of lock B might wait
for the IO A to complete. The ability to wait for a lock and IO
completions at the same time provides an efficient way to avoid such
deadlocks."
and in terms of effiency, even without unlocking the full potential yet,
Andres says:
"Futex wake support in io_uring is useful because it allows for more
efficient directed wakeups. For some "locks" postgres has queues
implemented in userspace, with wakeup logic that cannot easily be
implemented with FUTEX_WAKE_BITSET on a single "futex word" (imagine
waiting for journal flushes to have completed up to a certain point). Thus
a "lock release" sometimes need to wake up many processes in a row. A
quick-and-dirty conversion to doing these wakeups via io_uring lead to a
3% throughput increase, with 12% fewer context switches, albeit in a
fairly extreme workload."
Some basic io_uring futex support and test cases are available in the
liburing 'futex' branch:
https://git.kernel.dk/cgit/liburing/log/?h=futex
testing all of the variants. I originally wrote this code about a
month ago and Andres has been using it with postgres, and I'm not
aware of any bugs in it. That's not to say it's perfect, obviously,
and I welcome some feedback so we can move this forward and hash out
any potential issues.
include/linux/io_uring_types.h | 3 +
include/uapi/linux/futex.h | 17 +-
include/uapi/linux/io_uring.h | 4 +
io_uring/Makefile | 4 +-
io_uring/cancel.c | 5 +
io_uring/cancel.h | 4 +
io_uring/futex.c | 376 +++++++++++++++++++++++++++++++++
io_uring/futex.h | 36 ++++
io_uring/io_uring.c | 5 +
io_uring/opdef.c | 35 ++-
kernel/futex/futex.h | 92 +++++++-
kernel/futex/requeue.c | 3 +-
kernel/futex/syscalls.c | 41 ++--
kernel/futex/waitwake.c | 53 +++--
14 files changed, 630 insertions(+), 48 deletions(-)
You can also find the code here:
https://git.kernel.dk/cgit/linux/log/?h=io_uring-futex
V4:
- Refactor the prep setup so it's fully independent between the vectoed
and non-vectored futex handling.
- Ensure we -EINVAL any futex/futexv wait/waitv that specifies unused
fields.
- Fix a comment typo
- Update the patches from Peter.
- Fix two kerneldoc warnings
- Add a prep patch moving FUTEX2_MASK to futex.h
--
Jens Axboe
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 01/12] futex: Clarify FUTEX2 flags
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 02/12] futex: Extend the " Jens Axboe
` (11 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
From: Peter Zijlstra <[email protected]>
sys_futex_waitv() is part of the futex2 series (the first and only so
far) of syscalls and has a flags field per futex (as opposed to flags
being encoded in the futex op).
This new flags field has a new namespace, which unfortunately isn't
super explicit. Notably it currently takes FUTEX_32 and
FUTEX_PRIVATE_FLAG.
Introduce the FUTEX2 namespace to clarify this
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
---
include/uapi/linux/futex.h | 16 +++++++++++++---
kernel/futex/syscalls.c | 7 +++----
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/futex.h b/include/uapi/linux/futex.h
index 71a5df8d2689..0c5abb6aa8f8 100644
--- a/include/uapi/linux/futex.h
+++ b/include/uapi/linux/futex.h
@@ -44,10 +44,20 @@
FUTEX_PRIVATE_FLAG)
/*
- * Flags to specify the bit length of the futex word for futex2 syscalls.
- * Currently, only 32 is supported.
+ * Flags for futex2 syscalls.
*/
-#define FUTEX_32 2
+ /* 0x00 */
+ /* 0x01 */
+#define FUTEX2_32 0x02
+ /* 0x04 */
+ /* 0x08 */
+ /* 0x10 */
+ /* 0x20 */
+ /* 0x40 */
+#define FUTEX2_PRIVATE FUTEX_PRIVATE_FLAG
+
+/* do not use */
+#define FUTEX_32 FUTEX2_32 /* historical accident :-( */
/*
* Max numbers of elements in a futex_waitv array
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index a8074079b09e..42b6c2fac7db 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -183,8 +183,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3);
}
-/* Mask of available flags for each futex in futex_waitv list */
-#define FUTEXV_WAITER_MASK (FUTEX_32 | FUTEX_PRIVATE_FLAG)
+#define FUTEX2_MASK (FUTEX2_32 | FUTEX2_PRIVATE)
/**
* futex_parse_waitv - Parse a waitv array from userspace
@@ -205,10 +204,10 @@ static int futex_parse_waitv(struct futex_vector *futexv,
if (copy_from_user(&aux, &uwaitv[i], sizeof(aux)))
return -EFAULT;
- if ((aux.flags & ~FUTEXV_WAITER_MASK) || aux.__reserved)
+ if ((aux.flags & ~FUTEX2_MASK) || aux.__reserved)
return -EINVAL;
- if (!(aux.flags & FUTEX_32))
+ if (!(aux.flags & FUTEX2_32))
return -EINVAL;
futexv[i].w.flags = aux.flags;
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 02/12] futex: Extend the FUTEX2 flags
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
2023-07-28 16:42 ` [PATCH 01/12] futex: Clarify FUTEX2 flags Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 03/12] futex: Flag conversion Jens Axboe
` (10 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
From: Peter Zijlstra <[email protected]>
Add the definition for the missing but always intended extra sizes,
and add a NUMA flag for the planned numa extention.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
---
include/uapi/linux/futex.h | 7 ++++---
kernel/futex/syscalls.c | 9 +++++++--
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/futex.h b/include/uapi/linux/futex.h
index 0c5abb6aa8f8..0ed021acc1d9 100644
--- a/include/uapi/linux/futex.h
+++ b/include/uapi/linux/futex.h
@@ -46,10 +46,11 @@
/*
* Flags for futex2 syscalls.
*/
- /* 0x00 */
- /* 0x01 */
+#define FUTEX2_8 0x00
+#define FUTEX2_16 0x01
#define FUTEX2_32 0x02
- /* 0x04 */
+#define FUTEX2_64 0x03
+#define FUTEX2_NUMA 0x04
/* 0x08 */
/* 0x10 */
/* 0x20 */
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index 42b6c2fac7db..cfc8001e88ea 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -183,7 +183,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3);
}
-#define FUTEX2_MASK (FUTEX2_32 | FUTEX2_PRIVATE)
+#define FUTEX2_MASK (FUTEX2_64 | FUTEX2_PRIVATE)
/**
* futex_parse_waitv - Parse a waitv array from userspace
@@ -207,7 +207,12 @@ static int futex_parse_waitv(struct futex_vector *futexv,
if ((aux.flags & ~FUTEX2_MASK) || aux.__reserved)
return -EINVAL;
- if (!(aux.flags & FUTEX2_32))
+ if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) {
+ if ((aux.flags & FUTEX2_64) == FUTEX2_64)
+ return -EINVAL;
+ }
+
+ if ((aux.flags & FUTEX2_64) != FUTEX2_32)
return -EINVAL;
futexv[i].w.flags = aux.flags;
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 03/12] futex: Flag conversion
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
2023-07-28 16:42 ` [PATCH 01/12] futex: Clarify FUTEX2 flags Jens Axboe
2023-07-28 16:42 ` [PATCH 02/12] futex: Extend the " Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-08-09 18:04 ` Gabriel Krisman Bertazi
2023-07-28 16:42 ` [PATCH 04/12] futex: Validate futex value against futex size Jens Axboe
` (9 subsequent siblings)
12 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
From: Peter Zijlstra <[email protected]>
Futex has 3 sets of flags:
- legacy futex op bits
- futex2 flags
- internal flags
Add a few helpers to convert from the API flags into the internal
flags.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 64 +++++++++++++++++++++++++++++++++++++++--
kernel/futex/syscalls.c | 24 ++++++----------
kernel/futex/waitwake.c | 4 +--
3 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index b5379c0e6d6d..c0e04599904a 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -5,6 +5,7 @@
#include <linux/futex.h>
#include <linux/rtmutex.h>
#include <linux/sched/wake_q.h>
+#include <linux/compat.h>
#ifdef CONFIG_PREEMPT_RT
#include <linux/rcuwait.h>
@@ -16,8 +17,15 @@
* Futex flags used to encode options to functions and preserve them across
* restarts.
*/
+#define FLAGS_SIZE_8 0x00
+#define FLAGS_SIZE_16 0x01
+#define FLAGS_SIZE_32 0x02
+#define FLAGS_SIZE_64 0x03
+
+#define FLAGS_SIZE_MASK 0x03
+
#ifdef CONFIG_MMU
-# define FLAGS_SHARED 0x01
+# define FLAGS_SHARED 0x10
#else
/*
* NOMMU does not have per process address space. Let the compiler optimize
@@ -25,8 +33,58 @@
*/
# define FLAGS_SHARED 0x00
#endif
-#define FLAGS_CLOCKRT 0x02
-#define FLAGS_HAS_TIMEOUT 0x04
+#define FLAGS_CLOCKRT 0x20
+#define FLAGS_HAS_TIMEOUT 0x40
+#define FLAGS_NUMA 0x80
+
+/* FUTEX_ to FLAGS_ */
+static inline unsigned int futex_to_flags(unsigned int op)
+{
+ unsigned int flags = FLAGS_SIZE_32;
+
+ if (!(op & FUTEX_PRIVATE_FLAG))
+ flags |= FLAGS_SHARED;
+
+ if (op & FUTEX_CLOCK_REALTIME)
+ flags |= FLAGS_CLOCKRT;
+
+ return flags;
+}
+
+/* FUTEX2_ to FLAGS_ */
+static inline unsigned int futex2_to_flags(unsigned int flags2)
+{
+ unsigned int flags = flags2 & FUTEX2_64;
+
+ if (!(flags2 & FUTEX2_PRIVATE))
+ flags |= FLAGS_SHARED;
+
+ if (flags2 & FUTEX2_NUMA)
+ flags |= FLAGS_NUMA;
+
+ return flags;
+}
+
+static inline bool futex_flags_valid(unsigned int flags)
+{
+ /* Only 64bit futexes for 64bit code */
+ if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) {
+ if ((flags & FLAGS_SIZE_MASK) == FLAGS_SIZE_64)
+ return false;
+ }
+
+ /* Only 32bit futexes are implemented -- for now */
+ if ((flags & FLAGS_SIZE_MASK) != FLAGS_SIZE_32)
+ return false;
+
+ return true;
+}
+
+static inline unsigned int futex_size(unsigned int flags)
+{
+ unsigned int size = flags & FLAGS_SIZE_MASK;
+ return 1 << size; /* {0,1,2,3} -> {1,2,4,8} */
+}
#ifdef CONFIG_FAIL_FUTEX
extern bool should_fail_futex(bool fshared);
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index cfc8001e88ea..36824b64219a 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -1,6 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-or-later
-#include <linux/compat.h>
#include <linux/syscalls.h>
#include <linux/time_namespace.h>
@@ -85,15 +84,12 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
u32 __user *uaddr2, u32 val2, u32 val3)
{
+ unsigned int flags = futex_to_flags(op);
int cmd = op & FUTEX_CMD_MASK;
- unsigned int flags = 0;
- if (!(op & FUTEX_PRIVATE_FLAG))
- flags |= FLAGS_SHARED;
-
- if (op & FUTEX_CLOCK_REALTIME) {
- flags |= FLAGS_CLOCKRT;
- if (cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI &&
+ if (flags & FLAGS_CLOCKRT) {
+ if (cmd != FUTEX_WAIT_BITSET &&
+ cmd != FUTEX_WAIT_REQUEUE_PI &&
cmd != FUTEX_LOCK_PI2)
return -ENOSYS;
}
@@ -201,21 +197,19 @@ static int futex_parse_waitv(struct futex_vector *futexv,
unsigned int i;
for (i = 0; i < nr_futexes; i++) {
+ unsigned int flags;
+
if (copy_from_user(&aux, &uwaitv[i], sizeof(aux)))
return -EFAULT;
if ((aux.flags & ~FUTEX2_MASK) || aux.__reserved)
return -EINVAL;
- if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) {
- if ((aux.flags & FUTEX2_64) == FUTEX2_64)
- return -EINVAL;
- }
-
- if ((aux.flags & FUTEX2_64) != FUTEX2_32)
+ flags = futex2_to_flags(aux.flags);
+ if (!futex_flags_valid(flags))
return -EINVAL;
- futexv[i].w.flags = aux.flags;
+ futexv[i].w.flags = flags;
futexv[i].w.val = aux.val;
futexv[i].w.uaddr = aux.uaddr;
futexv[i].q = futex_q_init;
diff --git a/kernel/futex/waitwake.c b/kernel/futex/waitwake.c
index ba01b9408203..fa9757766103 100644
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -419,11 +419,11 @@ static int futex_wait_multiple_setup(struct futex_vector *vs, int count, int *wo
*/
retry:
for (i = 0; i < count; i++) {
- if ((vs[i].w.flags & FUTEX_PRIVATE_FLAG) && retry)
+ if (!(vs[i].w.flags & FLAGS_SHARED) && retry)
continue;
ret = get_futex_key(u64_to_user_ptr(vs[i].w.uaddr),
- !(vs[i].w.flags & FUTEX_PRIVATE_FLAG),
+ vs[i].w.flags & FLAGS_SHARED,
&vs[i].q.key, FUTEX_READ);
if (unlikely(ret))
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 04/12] futex: Validate futex value against futex size
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (2 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 03/12] futex: Flag conversion Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 05/12] futex: move FUTEX2_MASK to futex.h Jens Axboe
` (8 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
From: Peter Zijlstra <[email protected]>
Ensure the futex value fits in the given futex size. Since this adds a
constraint to an existing syscall, it might possibly change behaviour.
Currently the value would be truncated to a u32 and any high bits
would get silently lost.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 8 ++++++++
kernel/futex/syscalls.c | 3 +++
2 files changed, 11 insertions(+)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index c0e04599904a..d0a43d751e30 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -86,6 +86,14 @@ static inline unsigned int futex_size(unsigned int flags)
return 1 << size; /* {0,1,2,3} -> {1,2,4,8} */
}
+static inline bool futex_validate_input(unsigned int flags, u64 val)
+{
+ int bits = 8 * futex_size(flags);
+ if (bits < 64 && (val >> bits))
+ return false;
+ return true;
+}
+
#ifdef CONFIG_FAIL_FUTEX
extern bool should_fail_futex(bool fshared);
#else
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index 36824b64219a..d2b2bcf2a665 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -209,6 +209,9 @@ static int futex_parse_waitv(struct futex_vector *futexv,
if (!futex_flags_valid(flags))
return -EINVAL;
+ if (!futex_validate_input(flags, aux.val))
+ return -EINVAL;
+
futexv[i].w.flags = flags;
futexv[i].w.val = aux.val;
futexv[i].w.uaddr = aux.uaddr;
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 05/12] futex: move FUTEX2_MASK to futex.h
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (3 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 04/12] futex: Validate futex value against futex size Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 06/12] futex: factor out the futex wake handling Jens Axboe
` (7 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
We need this for validating the futex2 flags outside of the normal
futex syscalls.
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 2 ++
kernel/futex/syscalls.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index d0a43d751e30..2f8deaabc9bc 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -51,6 +51,8 @@ static inline unsigned int futex_to_flags(unsigned int op)
return flags;
}
+#define FUTEX2_MASK (FUTEX2_64 | FUTEX2_PRIVATE)
+
/* FUTEX2_ to FLAGS_ */
static inline unsigned int futex2_to_flags(unsigned int flags2)
{
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index d2b2bcf2a665..221c49797de9 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -179,8 +179,6 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3);
}
-#define FUTEX2_MASK (FUTEX2_64 | FUTEX2_PRIVATE)
-
/**
* futex_parse_waitv - Parse a waitv array from userspace
* @futexv: Kernel side list of waiters to be filled
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 06/12] futex: factor out the futex wake handling
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (4 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 05/12] futex: move FUTEX2_MASK to futex.h Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 07/12] futex: abstract out a __futex_wake_mark() helper Jens Axboe
` (6 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
In preparation for having another waker that isn't futex_wake_mark(),
add a wake handler in futex_q. No extra data is associated with the
handler outside of struct futex_q itself. futex_wake_mark() is defined as
the standard wakeup helper, now set through futex_q_init like other
defaults.
Normal sync futex waiting relies on wake_q holding tasks that should
be woken up. This is what futex_wake_mark() does, it'll unqueue the
futex and add the associated task to the wake queue. For async usage of
futex waiting, rather than having tasks sleeping on the futex, we'll
need to deal with a futex wake differently. For the planned io_uring
case, that means posting a completion event for the task in question.
Having a definable wake handler can help support that use case.
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 5 +++++
kernel/futex/requeue.c | 3 ++-
kernel/futex/waitwake.c | 6 +++---
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index 2f8deaabc9bc..bfc1e3c260b0 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -137,11 +137,15 @@ struct futex_pi_state {
union futex_key key;
} __randomize_layout;
+struct futex_q;
+typedef void (futex_wake_fn)(struct wake_q_head *wake_q, struct futex_q *q);
+
/**
* struct futex_q - The hashed futex queue entry, one per waiting task
* @list: priority-sorted list of tasks waiting on this futex
* @task: the task waiting on the futex
* @lock_ptr: the hash bucket lock
+ * @wake: the wake handler for this queue
* @key: the key the futex is hashed on
* @pi_state: optional priority inheritance state
* @rt_waiter: rt_waiter storage for use with requeue_pi
@@ -166,6 +170,7 @@ struct futex_q {
struct task_struct *task;
spinlock_t *lock_ptr;
+ futex_wake_fn *wake;
union futex_key key;
struct futex_pi_state *pi_state;
struct rt_mutex_waiter *rt_waiter;
diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
index cba8b1a6a4cc..e892bc6c41d8 100644
--- a/kernel/futex/requeue.c
+++ b/kernel/futex/requeue.c
@@ -58,6 +58,7 @@ enum {
const struct futex_q futex_q_init = {
/* list gets initialized in futex_queue()*/
+ .wake = futex_wake_mark,
.key = FUTEX_KEY_INIT,
.bitset = FUTEX_BITSET_MATCH_ANY,
.requeue_state = ATOMIC_INIT(Q_REQUEUE_PI_NONE),
@@ -591,7 +592,7 @@ int futex_requeue(u32 __user *uaddr1, unsigned int flags, u32 __user *uaddr2,
/* Plain futexes just wake or requeue and are done */
if (!requeue_pi) {
if (++task_count <= nr_wake)
- futex_wake_mark(&wake_q, this);
+ this->wake(&wake_q, this);
else
requeue_futex(this, hb1, hb2, &key2);
continue;
diff --git a/kernel/futex/waitwake.c b/kernel/futex/waitwake.c
index fa9757766103..0272b8c3b132 100644
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -174,7 +174,7 @@ int futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset)
if (!(this->bitset & bitset))
continue;
- futex_wake_mark(&wake_q, this);
+ this->wake(&wake_q, this);
if (++ret >= nr_wake)
break;
}
@@ -289,7 +289,7 @@ int futex_wake_op(u32 __user *uaddr1, unsigned int flags, u32 __user *uaddr2,
ret = -EINVAL;
goto out_unlock;
}
- futex_wake_mark(&wake_q, this);
+ this->wake(&wake_q, this);
if (++ret >= nr_wake)
break;
}
@@ -303,7 +303,7 @@ int futex_wake_op(u32 __user *uaddr1, unsigned int flags, u32 __user *uaddr2,
ret = -EINVAL;
goto out_unlock;
}
- futex_wake_mark(&wake_q, this);
+ this->wake(&wake_q, this);
if (++op_ret >= nr_wake2)
break;
}
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 07/12] futex: abstract out a __futex_wake_mark() helper
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (5 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 06/12] futex: factor out the futex wake handling Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 08/12] io_uring: add support for futex wake and wait Jens Axboe
` (5 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
Move the unqueue and lock_ptr clear into a helper that futex_wake_mark()
calls. Add it to the public functions as well, in preparation for using
it outside the core futex code.
Suggested-by: Peter Zijlstra <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 1 +
kernel/futex/waitwake.c | 33 ++++++++++++++++++++++-----------
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index bfc1e3c260b0..e04c74a34832 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -217,6 +217,7 @@ extern int futex_wait_setup(u32 __user *uaddr, u32 val, unsigned int flags,
struct futex_q *q, struct futex_hash_bucket **hb);
extern void futex_wait_queue(struct futex_hash_bucket *hb, struct futex_q *q,
struct hrtimer_sleeper *timeout);
+extern bool __futex_wake_mark(struct futex_q *q);
extern void futex_wake_mark(struct wake_q_head *wake_q, struct futex_q *q);
extern int fault_in_user_writeable(u32 __user *uaddr);
diff --git a/kernel/futex/waitwake.c b/kernel/futex/waitwake.c
index 0272b8c3b132..86f67f652b95 100644
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -106,20 +106,11 @@
* double_lock_hb() and double_unlock_hb(), respectively.
*/
-/*
- * The hash bucket lock must be held when this is called.
- * Afterwards, the futex_q must not be accessed. Callers
- * must ensure to later call wake_up_q() for the actual
- * wakeups to occur.
- */
-void futex_wake_mark(struct wake_q_head *wake_q, struct futex_q *q)
+bool __futex_wake_mark(struct futex_q *q)
{
- struct task_struct *p = q->task;
-
if (WARN(q->pi_state || q->rt_waiter, "refusing to wake PI futex\n"))
- return;
+ return false;
- get_task_struct(p);
__futex_unqueue(q);
/*
* The waiting task can free the futex_q as soon as q->lock_ptr = NULL
@@ -130,6 +121,26 @@ void futex_wake_mark(struct wake_q_head *wake_q, struct futex_q *q)
*/
smp_store_release(&q->lock_ptr, NULL);
+ return true;
+}
+
+/*
+ * The hash bucket lock must be held when this is called.
+ * Afterwards, the futex_q must not be accessed. Callers
+ * must ensure to later call wake_up_q() for the actual
+ * wakeups to occur.
+ */
+void futex_wake_mark(struct wake_q_head *wake_q, struct futex_q *q)
+{
+ struct task_struct *p = q->task;
+
+ get_task_struct(p);
+
+ if (!__futex_wake_mark(q)) {
+ put_task_struct(p);
+ return;
+ }
+
/*
* Queue the task for later wakeup for after we've released
* the hb->lock.
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 08/12] io_uring: add support for futex wake and wait
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (6 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 07/12] futex: abstract out a __futex_wake_mark() helper Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 09/12] futex: add wake_data to struct futex_q Jens Axboe
` (4 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
Add support for FUTEX_WAKE/WAIT primitives.
IORING_OP_FUTEX_WAKE is mix of FUTEX_WAKE and FUTEX_WAKE_BITSET, as
it does support passing in a bitset.
Similary, IORING_OP_FUTEX_WAIT is a mix of FUTEX_WAIT and
FUTEX_WAIT_BITSET.
FUTEX_WAKE is straight forward, as those can always be done directly from
the io_uring submission without needing async handling. For FUTEX_WAIT,
things are a bit more complicated. If the futex isn't ready, then we
rely on a callback via futex_queue->wake() when someone wakes up the
futex. From that calback, we queue up task_work with the original task,
which will post a CQE and wake it, if necessary.
Cancelations are supported, both from the application point-of-view,
but also to be able to cancel pending waits if the ring exits before
all events have occurred.
This is just the barebones wait/wake support. PI or REQUEUE support is
not added at this point, unclear if we might look into that later.
Likewise, explicit timeouts are not supported either. It is expected
that users that need timeouts would do so via the usual io_uring
mechanism to do that using linked timeouts.
Signed-off-by: Jens Axboe <[email protected]>
---
include/linux/io_uring_types.h | 3 +
include/uapi/linux/io_uring.h | 3 +
io_uring/Makefile | 4 +-
io_uring/cancel.c | 5 +
io_uring/cancel.h | 4 +
io_uring/futex.c | 230 +++++++++++++++++++++++++++++++++
io_uring/futex.h | 34 +++++
io_uring/io_uring.c | 5 +
io_uring/opdef.c | 24 +++-
9 files changed, 310 insertions(+), 2 deletions(-)
create mode 100644 io_uring/futex.c
create mode 100644 io_uring/futex.h
diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
index f04ce513fadb..a7f03d8d879f 100644
--- a/include/linux/io_uring_types.h
+++ b/include/linux/io_uring_types.h
@@ -273,6 +273,9 @@ struct io_ring_ctx {
struct io_wq_work_list locked_free_list;
unsigned int locked_free_nr;
+ struct hlist_head futex_list;
+ struct io_alloc_cache futex_cache;
+
const struct cred *sq_creds; /* cred used for __io_sq_thread() */
struct io_sq_data *sq_data; /* if using sq thread polling */
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index 36f9c73082de..3bd2d765f593 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -65,6 +65,7 @@ struct io_uring_sqe {
__u32 xattr_flags;
__u32 msg_ring_flags;
__u32 uring_cmd_flags;
+ __u32 futex_flags;
};
__u64 user_data; /* data to be passed back at completion time */
/* pack this to avoid bogus arm OABI complaints */
@@ -235,6 +236,8 @@ enum io_uring_op {
IORING_OP_URING_CMD,
IORING_OP_SEND_ZC,
IORING_OP_SENDMSG_ZC,
+ IORING_OP_FUTEX_WAIT,
+ IORING_OP_FUTEX_WAKE,
/* this goes last, obviously */
IORING_OP_LAST,
diff --git a/io_uring/Makefile b/io_uring/Makefile
index 8cc8e5387a75..2e4779bc550c 100644
--- a/io_uring/Makefile
+++ b/io_uring/Makefile
@@ -7,5 +7,7 @@ obj-$(CONFIG_IO_URING) += io_uring.o xattr.o nop.o fs.o splice.o \
openclose.o uring_cmd.o epoll.o \
statx.o net.o msg_ring.o timeout.o \
sqpoll.o fdinfo.o tctx.o poll.o \
- cancel.o kbuf.o rsrc.o rw.o opdef.o notif.o
+ cancel.o kbuf.o rsrc.o rw.o opdef.o \
+ notif.o
obj-$(CONFIG_IO_WQ) += io-wq.o
+obj-$(CONFIG_FUTEX) += futex.o
diff --git a/io_uring/cancel.c b/io_uring/cancel.c
index 7b23607cf4af..3dba8ccb1cd8 100644
--- a/io_uring/cancel.c
+++ b/io_uring/cancel.c
@@ -15,6 +15,7 @@
#include "tctx.h"
#include "poll.h"
#include "timeout.h"
+#include "futex.h"
#include "cancel.h"
struct io_cancel {
@@ -119,6 +120,10 @@ int io_try_cancel(struct io_uring_task *tctx, struct io_cancel_data *cd,
if (ret != -ENOENT)
return ret;
+ ret = io_futex_cancel(ctx, cd, issue_flags);
+ if (ret != -ENOENT)
+ return ret;
+
spin_lock(&ctx->completion_lock);
if (!(cd->flags & IORING_ASYNC_CANCEL_FD))
ret = io_timeout_cancel(ctx, cd);
diff --git a/io_uring/cancel.h b/io_uring/cancel.h
index fc98622e6166..c0a8e7c520b6 100644
--- a/io_uring/cancel.h
+++ b/io_uring/cancel.h
@@ -1,4 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
+#ifndef IORING_CANCEL_H
+#define IORING_CANCEL_H
#include <linux/io_uring_types.h>
@@ -22,3 +24,5 @@ void init_hash_table(struct io_hash_table *table, unsigned size);
int io_sync_cancel(struct io_ring_ctx *ctx, void __user *arg);
bool io_cancel_req_match(struct io_kiocb *req, struct io_cancel_data *cd);
+
+#endif
diff --git a/io_uring/futex.c b/io_uring/futex.c
new file mode 100644
index 000000000000..f58ab33bfb32
--- /dev/null
+++ b/io_uring/futex.c
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/fs.h>
+#include <linux/file.h>
+#include <linux/io_uring.h>
+
+#include <uapi/linux/io_uring.h>
+
+#include "../kernel/futex/futex.h"
+#include "io_uring.h"
+#include "rsrc.h"
+#include "futex.h"
+
+struct io_futex {
+ struct file *file;
+ u32 __user *uaddr;
+ unsigned long futex_val;
+ unsigned long futex_mask;
+ u32 futex_flags;
+};
+
+struct io_futex_data {
+ union {
+ struct futex_q q;
+ struct io_cache_entry cache;
+ };
+ struct io_kiocb *req;
+};
+
+void io_futex_cache_init(struct io_ring_ctx *ctx)
+{
+ io_alloc_cache_init(&ctx->futex_cache, IO_NODE_ALLOC_CACHE_MAX,
+ sizeof(struct io_futex_data));
+}
+
+static void io_futex_cache_entry_free(struct io_cache_entry *entry)
+{
+ kfree(container_of(entry, struct io_futex_data, cache));
+}
+
+void io_futex_cache_free(struct io_ring_ctx *ctx)
+{
+ io_alloc_cache_free(&ctx->futex_cache, io_futex_cache_entry_free);
+}
+
+static void io_futex_complete(struct io_kiocb *req, struct io_tw_state *ts)
+{
+ struct io_futex_data *ifd = req->async_data;
+ struct io_ring_ctx *ctx = req->ctx;
+
+ io_tw_lock(ctx, ts);
+ if (!io_alloc_cache_put(&ctx->futex_cache, &ifd->cache))
+ kfree(ifd);
+ req->async_data = NULL;
+ hlist_del_init(&req->hash_node);
+ io_req_task_complete(req, ts);
+}
+
+static bool __io_futex_cancel(struct io_ring_ctx *ctx, struct io_kiocb *req)
+{
+ struct io_futex_data *ifd = req->async_data;
+
+ /* futex wake already done or in progress */
+ if (!futex_unqueue(&ifd->q))
+ return false;
+
+ hlist_del_init(&req->hash_node);
+ io_req_set_res(req, -ECANCELED, 0);
+ req->io_task_work.func = io_futex_complete;
+ io_req_task_work_add(req);
+ return true;
+}
+
+int io_futex_cancel(struct io_ring_ctx *ctx, struct io_cancel_data *cd,
+ unsigned int issue_flags)
+{
+ struct hlist_node *tmp;
+ struct io_kiocb *req;
+ int nr = 0;
+
+ if (cd->flags & (IORING_ASYNC_CANCEL_FD|IORING_ASYNC_CANCEL_FD_FIXED))
+ return -ENOENT;
+
+ io_ring_submit_lock(ctx, issue_flags);
+ hlist_for_each_entry_safe(req, tmp, &ctx->futex_list, hash_node) {
+ if (req->cqe.user_data != cd->data &&
+ !(cd->flags & IORING_ASYNC_CANCEL_ANY))
+ continue;
+ if (__io_futex_cancel(ctx, req))
+ nr++;
+ if (!(cd->flags & IORING_ASYNC_CANCEL_ALL))
+ break;
+ }
+ io_ring_submit_unlock(ctx, issue_flags);
+
+ if (nr)
+ return nr;
+
+ return -ENOENT;
+}
+
+bool io_futex_remove_all(struct io_ring_ctx *ctx, struct task_struct *task,
+ bool cancel_all)
+{
+ struct hlist_node *tmp;
+ struct io_kiocb *req;
+ bool found = false;
+
+ lockdep_assert_held(&ctx->uring_lock);
+
+ hlist_for_each_entry_safe(req, tmp, &ctx->futex_list, hash_node) {
+ if (!io_match_task_safe(req, task, cancel_all))
+ continue;
+ __io_futex_cancel(ctx, req);
+ found = true;
+ }
+
+ return found;
+}
+
+int io_futex_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
+{
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ u32 flags;
+
+ if (unlikely(sqe->fd || sqe->len || sqe->buf_index || sqe->file_index))
+ return -EINVAL;
+
+ iof->uaddr = u64_to_user_ptr(READ_ONCE(sqe->addr));
+ iof->futex_val = READ_ONCE(sqe->addr2);
+ iof->futex_mask = READ_ONCE(sqe->addr3);
+ flags = READ_ONCE(sqe->futex_flags);
+
+ if (flags & ~FUTEX2_MASK)
+ return -EINVAL;
+
+ iof->futex_flags = futex2_to_flags(flags);
+ if (!futex_flags_valid(iof->futex_flags))
+ return -EINVAL;
+
+ if (!futex_validate_input(iof->futex_flags, iof->futex_val) ||
+ !futex_validate_input(iof->futex_flags, iof->futex_mask))
+ return -EINVAL;
+
+ return 0;
+}
+
+static void io_futex_wake_fn(struct wake_q_head *wake_q, struct futex_q *q)
+{
+ struct io_futex_data *ifd = container_of(q, struct io_futex_data, q);
+ struct io_kiocb *req = ifd->req;
+
+ if (unlikely(!__futex_wake_mark(q)))
+ return;
+
+ io_req_set_res(req, 0, 0);
+ req->io_task_work.func = io_futex_complete;
+ io_req_task_work_add(req);
+}
+
+static struct io_futex_data *io_alloc_ifd(struct io_ring_ctx *ctx)
+{
+ struct io_cache_entry *entry;
+
+ entry = io_alloc_cache_get(&ctx->futex_cache);
+ if (entry)
+ return container_of(entry, struct io_futex_data, cache);
+
+ return kmalloc(sizeof(struct io_futex_data), GFP_NOWAIT);
+}
+
+int io_futex_wait(struct io_kiocb *req, unsigned int issue_flags)
+{
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ struct io_ring_ctx *ctx = req->ctx;
+ struct io_futex_data *ifd = NULL;
+ struct futex_hash_bucket *hb;
+ int ret;
+
+ if (!iof->futex_mask) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ io_ring_submit_lock(ctx, issue_flags);
+ ifd = io_alloc_ifd(ctx);
+ if (!ifd) {
+ ret = -ENOMEM;
+ goto done_unlock;
+ }
+
+ req->async_data = ifd;
+ ifd->q = futex_q_init;
+ ifd->q.bitset = iof->futex_mask;
+ ifd->q.wake = io_futex_wake_fn;
+ ifd->req = req;
+
+ ret = futex_wait_setup(iof->uaddr, iof->futex_val,
+ futex2_to_flags(iof->futex_flags), &ifd->q, &hb);
+ if (!ret) {
+ hlist_add_head(&req->hash_node, &ctx->futex_list);
+ io_ring_submit_unlock(ctx, issue_flags);
+
+ futex_queue(&ifd->q, hb);
+ return IOU_ISSUE_SKIP_COMPLETE;
+ }
+
+done_unlock:
+ io_ring_submit_unlock(ctx, issue_flags);
+done:
+ if (ret < 0)
+ req_set_fail(req);
+ io_req_set_res(req, ret, 0);
+ kfree(ifd);
+ return IOU_OK;
+}
+
+int io_futex_wake(struct io_kiocb *req, unsigned int issue_flags)
+{
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ int ret;
+
+ ret = futex_wake(iof->uaddr, futex2_to_flags(iof->futex_flags),
+ iof->futex_val, iof->futex_mask);
+ if (ret < 0)
+ req_set_fail(req);
+ io_req_set_res(req, ret, 0);
+ return IOU_OK;
+}
diff --git a/io_uring/futex.h b/io_uring/futex.h
new file mode 100644
index 000000000000..ddc9e0d73c52
--- /dev/null
+++ b/io_uring/futex.h
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "cancel.h"
+
+int io_futex_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe);
+int io_futex_wait(struct io_kiocb *req, unsigned int issue_flags);
+int io_futex_wake(struct io_kiocb *req, unsigned int issue_flags);
+
+#if defined(CONFIG_FUTEX)
+int io_futex_cancel(struct io_ring_ctx *ctx, struct io_cancel_data *cd,
+ unsigned int issue_flags);
+bool io_futex_remove_all(struct io_ring_ctx *ctx, struct task_struct *task,
+ bool cancel_all);
+void io_futex_cache_init(struct io_ring_ctx *ctx);
+void io_futex_cache_free(struct io_ring_ctx *ctx);
+#else
+static inline int io_futex_cancel(struct io_ring_ctx *ctx,
+ struct io_cancel_data *cd,
+ unsigned int issue_flags)
+{
+ return 0;
+}
+static inline bool io_futex_remove_all(struct io_ring_ctx *ctx,
+ struct task_struct *task, bool cancel_all)
+{
+ return false;
+}
+static inline void io_futex_cache_init(struct io_ring_ctx *ctx)
+{
+}
+static inline void io_futex_cache_free(struct io_ring_ctx *ctx)
+{
+}
+#endif
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 135da2fd0eda..e52cbdcb29b8 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -92,6 +92,7 @@
#include "cancel.h"
#include "net.h"
#include "notif.h"
+#include "futex.h"
#include "timeout.h"
#include "poll.h"
@@ -330,6 +331,7 @@ static __cold struct io_ring_ctx *io_ring_ctx_alloc(struct io_uring_params *p)
sizeof(struct async_poll));
io_alloc_cache_init(&ctx->netmsg_cache, IO_ALLOC_CACHE_MAX,
sizeof(struct io_async_msghdr));
+ io_futex_cache_init(ctx);
init_completion(&ctx->ref_comp);
xa_init_flags(&ctx->personalities, XA_FLAGS_ALLOC1);
mutex_init(&ctx->uring_lock);
@@ -349,6 +351,7 @@ static __cold struct io_ring_ctx *io_ring_ctx_alloc(struct io_uring_params *p)
INIT_LIST_HEAD(&ctx->tctx_list);
ctx->submit_state.free_list.next = NULL;
INIT_WQ_LIST(&ctx->locked_free_list);
+ INIT_HLIST_HEAD(&ctx->futex_list);
INIT_DELAYED_WORK(&ctx->fallback_work, io_fallback_req_func);
INIT_WQ_LIST(&ctx->submit_state.compl_reqs);
return ctx;
@@ -2869,6 +2872,7 @@ static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)
io_eventfd_unregister(ctx);
io_alloc_cache_free(&ctx->apoll_cache, io_apoll_cache_free);
io_alloc_cache_free(&ctx->netmsg_cache, io_netmsg_cache_free);
+ io_futex_cache_free(ctx);
io_destroy_buffers(ctx);
mutex_unlock(&ctx->uring_lock);
if (ctx->sq_creds)
@@ -3281,6 +3285,7 @@ static __cold bool io_uring_try_cancel_requests(struct io_ring_ctx *ctx,
ret |= io_cancel_defer_files(ctx, task, cancel_all);
mutex_lock(&ctx->uring_lock);
ret |= io_poll_remove_all(ctx, task, cancel_all);
+ ret |= io_futex_remove_all(ctx, task, cancel_all);
mutex_unlock(&ctx->uring_lock);
ret |= io_kill_timeouts(ctx, task, cancel_all);
if (task)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index 3b9c6489b8b6..c9f23c21a031 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -33,6 +33,7 @@
#include "poll.h"
#include "cancel.h"
#include "rw.h"
+#include "futex.h"
static int io_no_issue(struct io_kiocb *req, unsigned int issue_flags)
{
@@ -426,11 +427,26 @@ const struct io_issue_def io_issue_defs[] = {
.issue = io_sendmsg_zc,
#else
.prep = io_eopnotsupp_prep,
+#endif
+ },
+ [IORING_OP_FUTEX_WAIT] = {
+#if defined(CONFIG_FUTEX)
+ .prep = io_futex_prep,
+ .issue = io_futex_wait,
+#else
+ .prep = io_eopnotsupp_prep,
+#endif
+ },
+ [IORING_OP_FUTEX_WAKE] = {
+#if defined(CONFIG_FUTEX)
+ .prep = io_futex_prep,
+ .issue = io_futex_wake,
+#else
+ .prep = io_eopnotsupp_prep,
#endif
},
};
-
const struct io_cold_def io_cold_defs[] = {
[IORING_OP_NOP] = {
.name = "NOP",
@@ -648,6 +664,12 @@ const struct io_cold_def io_cold_defs[] = {
.fail = io_sendrecv_fail,
#endif
},
+ [IORING_OP_FUTEX_WAIT] = {
+ .name = "FUTEX_WAIT",
+ },
+ [IORING_OP_FUTEX_WAKE] = {
+ .name = "FUTEX_WAKE",
+ },
};
const char *io_uring_get_opcode(u8 opcode)
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 09/12] futex: add wake_data to struct futex_q
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (7 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 08/12] io_uring: add support for futex wake and wait Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 10/12] futex: make futex_parse_waitv() available as a helper Jens Axboe
` (3 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
With handling multiple futex_q for waitv, we cannot easily go from the
futex_q to data related to that request or queue. Add a wake_data
argument that belongs to the wake handler assigned.
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index e04c74a34832..4633c99ea4b6 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -146,6 +146,7 @@ typedef void (futex_wake_fn)(struct wake_q_head *wake_q, struct futex_q *q);
* @task: the task waiting on the futex
* @lock_ptr: the hash bucket lock
* @wake: the wake handler for this queue
+ * @wake_data: data associated with the wake handler
* @key: the key the futex is hashed on
* @pi_state: optional priority inheritance state
* @rt_waiter: rt_waiter storage for use with requeue_pi
@@ -171,6 +172,7 @@ struct futex_q {
struct task_struct *task;
spinlock_t *lock_ptr;
futex_wake_fn *wake;
+ void *wake_data;
union futex_key key;
struct futex_pi_state *pi_state;
struct rt_mutex_waiter *rt_waiter;
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 10/12] futex: make futex_parse_waitv() available as a helper
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (8 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 09/12] futex: add wake_data to struct futex_q Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 11/12] futex: make the vectored futex operations available Jens Axboe
` (2 subsequent siblings)
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
To make it more generically useful, augment it with allowing the caller
to pass in the wake handler and wake data. Convert the futex_waitv()
syscall, passing in the default handlers.
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 5 +++++
kernel/futex/syscalls.c | 14 ++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index 4633c99ea4b6..6a13275ca231 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -355,6 +355,11 @@ struct futex_vector {
struct futex_q q;
};
+extern int futex_parse_waitv(struct futex_vector *futexv,
+ struct futex_waitv __user *uwaitv,
+ unsigned int nr_futexes, futex_wake_fn *wake,
+ void *wake_data);
+
extern int futex_wait_multiple(struct futex_vector *vs, unsigned int count,
struct hrtimer_sleeper *to);
diff --git a/kernel/futex/syscalls.c b/kernel/futex/syscalls.c
index 221c49797de9..bbb3b3ceef51 100644
--- a/kernel/futex/syscalls.c
+++ b/kernel/futex/syscalls.c
@@ -184,12 +184,15 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
* @futexv: Kernel side list of waiters to be filled
* @uwaitv: Userspace list to be parsed
* @nr_futexes: Length of futexv
+ * @wake: Wake to call when futex is woken
+ * @wake_data: Data for the wake handler
*
* Return: Error code on failure, 0 on success
*/
-static int futex_parse_waitv(struct futex_vector *futexv,
- struct futex_waitv __user *uwaitv,
- unsigned int nr_futexes)
+int futex_parse_waitv(struct futex_vector *futexv,
+ struct futex_waitv __user *uwaitv,
+ unsigned int nr_futexes, futex_wake_fn *wake,
+ void *wake_data)
{
struct futex_waitv aux;
unsigned int i;
@@ -214,6 +217,8 @@ static int futex_parse_waitv(struct futex_vector *futexv,
futexv[i].w.val = aux.val;
futexv[i].w.uaddr = aux.uaddr;
futexv[i].q = futex_q_init;
+ futexv[i].q.wake = wake;
+ futexv[i].q.wake_data = wake_data;
}
return 0;
@@ -290,7 +295,8 @@ SYSCALL_DEFINE5(futex_waitv, struct futex_waitv __user *, waiters,
goto destroy_timer;
}
- ret = futex_parse_waitv(futexv, waiters, nr_futexes);
+ ret = futex_parse_waitv(futexv, waiters, nr_futexes, futex_wake_mark,
+ NULL);
if (!ret)
ret = futex_wait_multiple(futexv, nr_futexes, timeout ? &to : NULL);
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 11/12] futex: make the vectored futex operations available
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (9 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 10/12] futex: make futex_parse_waitv() available as a helper Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-28 16:42 ` [PATCH 12/12] io_uring: add support for vectored futex waits Jens Axboe
2023-07-31 16:06 ` [PATCHSET v4] Add io_uring futex/futexv support Thomas Gleixner
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
Rename unqueue_multiple() as futex_unqueue_multiple(), and make both
that and futex_wait_multiple_setup() available for external users. This
is in preparation for wiring up vectored waits in io_uring.
Signed-off-by: Jens Axboe <[email protected]>
---
kernel/futex/futex.h | 5 +++++
kernel/futex/waitwake.c | 10 +++++-----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
index 6a13275ca231..b099b849aecb 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -360,6 +360,11 @@ extern int futex_parse_waitv(struct futex_vector *futexv,
unsigned int nr_futexes, futex_wake_fn *wake,
void *wake_data);
+extern int futex_wait_multiple_setup(struct futex_vector *vs, int count,
+ int *woken);
+
+extern int futex_unqueue_multiple(struct futex_vector *v, int count);
+
extern int futex_wait_multiple(struct futex_vector *vs, unsigned int count,
struct hrtimer_sleeper *to);
diff --git a/kernel/futex/waitwake.c b/kernel/futex/waitwake.c
index 86f67f652b95..6c8fb7300558 100644
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -369,7 +369,7 @@ void futex_wait_queue(struct futex_hash_bucket *hb, struct futex_q *q,
}
/**
- * unqueue_multiple - Remove various futexes from their hash bucket
+ * futex_unqueue_multiple - Remove various futexes from their hash bucket
* @v: The list of futexes to unqueue
* @count: Number of futexes in the list
*
@@ -379,7 +379,7 @@ void futex_wait_queue(struct futex_hash_bucket *hb, struct futex_q *q,
* - >=0 - Index of the last futex that was awoken;
* - -1 - No futex was awoken
*/
-static int unqueue_multiple(struct futex_vector *v, int count)
+int futex_unqueue_multiple(struct futex_vector *v, int count)
{
int ret = -1, i;
@@ -407,7 +407,7 @@ static int unqueue_multiple(struct futex_vector *v, int count)
* - 0 - Success
* - <0 - -EFAULT, -EWOULDBLOCK or -EINVAL
*/
-static int futex_wait_multiple_setup(struct futex_vector *vs, int count, int *woken)
+int futex_wait_multiple_setup(struct futex_vector *vs, int count, int *woken)
{
struct futex_hash_bucket *hb;
bool retry = false;
@@ -469,7 +469,7 @@ static int futex_wait_multiple_setup(struct futex_vector *vs, int count, int *wo
* was woken, we don't return error and return this index to
* userspace
*/
- *woken = unqueue_multiple(vs, i);
+ *woken = futex_unqueue_multiple(vs, i);
if (*woken >= 0)
return 1;
@@ -554,7 +554,7 @@ int futex_wait_multiple(struct futex_vector *vs, unsigned int count,
__set_current_state(TASK_RUNNING);
- ret = unqueue_multiple(vs, count);
+ ret = futex_unqueue_multiple(vs, count);
if (ret >= 0)
return ret;
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 12/12] io_uring: add support for vectored futex waits
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (10 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 11/12] futex: make the vectored futex operations available Jens Axboe
@ 2023-07-28 16:42 ` Jens Axboe
2023-07-31 16:06 ` [PATCHSET v4] Add io_uring futex/futexv support Thomas Gleixner
12 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-07-28 16:42 UTC (permalink / raw)
To: io-uring, linux-kernel; +Cc: peterz, andres, tglx, Jens Axboe
This adds support for IORING_OP_FUTEX_WAITV, which allows registering a
notification for a number of futexes at once. If one of the futexes are
woken, then the request will complete with the index of the futex that got
woken as the result. This is identical to what the normal vectored futex
waitv operation does.
Use like IORING_OP_FUTEX_WAIT, except sqe->addr must now contain the a
pointer to a struct futex_waitv array, and sqe->off must now contain the
number of elements in that array.
Waiting on N futexes could be done with IORING_OP_FUTEX_WAIT as well,
but that punts a lot of the work to the application:
1) Application would need to submit N IORING_OP_FUTEX_WAIT requests,
rather than just a single IORING_OP_FUTEX_WAITV.
2) When one futex is woken, application would need to cancel the
remaining N-1 requests that didn't trigger.
While this is of course doable, having a single vectored futex wait
makes for much simpler application code.
Signed-off-by: Jens Axboe <[email protected]>
---
include/uapi/linux/io_uring.h | 1 +
io_uring/futex.c | 164 ++++++++++++++++++++++++++++++++--
io_uring/futex.h | 2 +
io_uring/opdef.c | 11 +++
4 files changed, 169 insertions(+), 9 deletions(-)
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index 3bd2d765f593..420f38675769 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -238,6 +238,7 @@ enum io_uring_op {
IORING_OP_SENDMSG_ZC,
IORING_OP_FUTEX_WAIT,
IORING_OP_FUTEX_WAKE,
+ IORING_OP_FUTEX_WAITV,
/* this goes last, obviously */
IORING_OP_LAST,
diff --git a/io_uring/futex.c b/io_uring/futex.c
index f58ab33bfb32..c7936a34319a 100644
--- a/io_uring/futex.c
+++ b/io_uring/futex.c
@@ -14,10 +14,15 @@
struct io_futex {
struct file *file;
- u32 __user *uaddr;
+ union {
+ u32 __user *uaddr;
+ struct futex_waitv __user *uwaitv;
+ };
unsigned long futex_val;
unsigned long futex_mask;
+ unsigned long futexv_owned;
u32 futex_flags;
+ unsigned int futex_nr;
};
struct io_futex_data {
@@ -44,6 +49,13 @@ void io_futex_cache_free(struct io_ring_ctx *ctx)
io_alloc_cache_free(&ctx->futex_cache, io_futex_cache_entry_free);
}
+static void __io_futex_complete(struct io_kiocb *req, struct io_tw_state *ts)
+{
+ req->async_data = NULL;
+ hlist_del_init(&req->hash_node);
+ io_req_task_complete(req, ts);
+}
+
static void io_futex_complete(struct io_kiocb *req, struct io_tw_state *ts)
{
struct io_futex_data *ifd = req->async_data;
@@ -52,22 +64,59 @@ static void io_futex_complete(struct io_kiocb *req, struct io_tw_state *ts)
io_tw_lock(ctx, ts);
if (!io_alloc_cache_put(&ctx->futex_cache, &ifd->cache))
kfree(ifd);
- req->async_data = NULL;
- hlist_del_init(&req->hash_node);
- io_req_task_complete(req, ts);
+ __io_futex_complete(req, ts);
}
-static bool __io_futex_cancel(struct io_ring_ctx *ctx, struct io_kiocb *req)
+static void io_futexv_complete(struct io_kiocb *req, struct io_tw_state *ts)
{
- struct io_futex_data *ifd = req->async_data;
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ struct futex_vector *futexv = req->async_data;
+ struct io_ring_ctx *ctx = req->ctx;
+ int res = 0;
- /* futex wake already done or in progress */
- if (!futex_unqueue(&ifd->q))
+ io_tw_lock(ctx, ts);
+
+ res = futex_unqueue_multiple(futexv, iof->futex_nr);
+ if (res != -1)
+ io_req_set_res(req, res, 0);
+
+ kfree(req->async_data);
+ req->flags &= ~REQ_F_ASYNC_DATA;
+ __io_futex_complete(req, ts);
+}
+
+static bool io_futexv_claimed(struct io_futex *iof)
+{
+ return test_bit(0, &iof->futexv_owned);
+}
+
+static bool io_futexv_claim(struct io_futex *iof)
+{
+ if (test_bit(0, &iof->futexv_owned) ||
+ test_and_set_bit(0, &iof->futexv_owned))
return false;
+ return true;
+}
+
+static bool __io_futex_cancel(struct io_ring_ctx *ctx, struct io_kiocb *req)
+{
+ /* futex wake already done or in progress */
+ if (req->opcode == IORING_OP_FUTEX_WAIT) {
+ struct io_futex_data *ifd = req->async_data;
+
+ if (!futex_unqueue(&ifd->q))
+ return false;
+ req->io_task_work.func = io_futex_complete;
+ } else {
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+
+ if (!io_futexv_claim(iof))
+ return false;
+ req->io_task_work.func = io_futexv_complete;
+ }
hlist_del_init(&req->hash_node);
io_req_set_res(req, -ECANCELED, 0);
- req->io_task_work.func = io_futex_complete;
io_req_task_work_add(req);
return true;
}
@@ -146,6 +195,54 @@ int io_futex_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
return 0;
}
+static void io_futex_wakev_fn(struct wake_q_head *wake_q, struct futex_q *q)
+{
+ struct io_kiocb *req = q->wake_data;
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+
+ if (!io_futexv_claim(iof))
+ return;
+ if (unlikely(!__futex_wake_mark(q)))
+ return;
+
+ io_req_set_res(req, 0, 0);
+ req->io_task_work.func = io_futexv_complete;
+ io_req_task_work_add(req);
+}
+
+int io_futexv_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
+{
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ struct futex_vector *futexv;
+ int ret;
+
+ /* No flags or mask supported for waitv */
+ if (unlikely(sqe->fd || sqe->buf_index || sqe->file_index ||
+ sqe->addr2 || sqe->addr3))
+ return -EINVAL;
+
+ iof->uaddr = u64_to_user_ptr(READ_ONCE(sqe->addr));
+ iof->futex_nr = READ_ONCE(sqe->len);
+ if (!iof->futex_nr || iof->futex_nr > FUTEX_WAITV_MAX)
+ return -EINVAL;
+
+ futexv = kcalloc(iof->futex_nr, sizeof(*futexv), GFP_KERNEL);
+ if (!futexv)
+ return -ENOMEM;
+
+ ret = futex_parse_waitv(futexv, iof->uwaitv, iof->futex_nr,
+ io_futex_wakev_fn, req);
+ if (ret) {
+ kfree(futexv);
+ return ret;
+ }
+
+ iof->futexv_owned = 0;
+ req->flags |= REQ_F_ASYNC_DATA;
+ req->async_data = futexv;
+ return 0;
+}
+
static void io_futex_wake_fn(struct wake_q_head *wake_q, struct futex_q *q)
{
struct io_futex_data *ifd = container_of(q, struct io_futex_data, q);
@@ -170,6 +267,55 @@ static struct io_futex_data *io_alloc_ifd(struct io_ring_ctx *ctx)
return kmalloc(sizeof(struct io_futex_data), GFP_NOWAIT);
}
+int io_futexv_wait(struct io_kiocb *req, unsigned int issue_flags)
+{
+ struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
+ struct futex_vector *futexv = req->async_data;
+ struct io_ring_ctx *ctx = req->ctx;
+ int ret, woken = -1;
+
+ io_ring_submit_lock(ctx, issue_flags);
+
+ ret = futex_wait_multiple_setup(futexv, iof->futex_nr, &woken);
+
+ /*
+ * The above call leaves us potentially non-running. This is fine
+ * for the sync syscall as it'll be blocking unless we already got
+ * one of the futexes woken, but it obviously won't work for an async
+ * invocation. Mark us runnable again.
+ */
+ __set_current_state(TASK_RUNNING);
+
+ /*
+ * We got woken while setting up, let that side do the completion
+ */
+ if (io_futexv_claimed(iof)) {
+skip:
+ io_ring_submit_unlock(ctx, issue_flags);
+ return IOU_ISSUE_SKIP_COMPLETE;
+ }
+
+ /*
+ * 0 return means that we successfully setup the waiters, and that
+ * nobody triggered a wakeup while we were doing so. < 0 or 1 return
+ * is either an error or we got a wakeup while setting up.
+ */
+ if (!ret) {
+ hlist_add_head(&req->hash_node, &ctx->futex_list);
+ goto skip;
+ }
+
+ io_ring_submit_unlock(ctx, issue_flags);
+ if (ret < 0)
+ req_set_fail(req);
+ else if (woken != -1)
+ ret = woken;
+ io_req_set_res(req, ret, 0);
+ kfree(futexv);
+ req->flags &= ~REQ_F_ASYNC_DATA;
+ return IOU_OK;
+}
+
int io_futex_wait(struct io_kiocb *req, unsigned int issue_flags)
{
struct io_futex *iof = io_kiocb_to_cmd(req, struct io_futex);
diff --git a/io_uring/futex.h b/io_uring/futex.h
index ddc9e0d73c52..0847e9e8a127 100644
--- a/io_uring/futex.h
+++ b/io_uring/futex.h
@@ -3,7 +3,9 @@
#include "cancel.h"
int io_futex_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe);
+int io_futexv_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe);
int io_futex_wait(struct io_kiocb *req, unsigned int issue_flags);
+int io_futexv_wait(struct io_kiocb *req, unsigned int issue_flags);
int io_futex_wake(struct io_kiocb *req, unsigned int issue_flags);
#if defined(CONFIG_FUTEX)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index c9f23c21a031..b9e1e12cac9c 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -443,6 +443,14 @@ const struct io_issue_def io_issue_defs[] = {
.issue = io_futex_wake,
#else
.prep = io_eopnotsupp_prep,
+#endif
+ },
+ [IORING_OP_FUTEX_WAITV] = {
+#if defined(CONFIG_FUTEX)
+ .prep = io_futexv_prep,
+ .issue = io_futexv_wait,
+#else
+ .prep = io_eopnotsupp_prep,
#endif
},
};
@@ -670,6 +678,9 @@ const struct io_cold_def io_cold_defs[] = {
[IORING_OP_FUTEX_WAKE] = {
.name = "FUTEX_WAKE",
},
+ [IORING_OP_FUTEX_WAITV] = {
+ .name = "FUTEX_WAITV",
+ },
};
const char *io_uring_get_opcode(u8 opcode)
--
2.40.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
` (11 preceding siblings ...)
2023-07-28 16:42 ` [PATCH 12/12] io_uring: add support for vectored futex waits Jens Axboe
@ 2023-07-31 16:06 ` Thomas Gleixner
2023-08-06 16:44 ` Jens Axboe
12 siblings, 1 reply; 22+ messages in thread
From: Thomas Gleixner @ 2023-07-31 16:06 UTC (permalink / raw)
To: Jens Axboe, io-uring, linux-kernel; +Cc: peterz, andres
On Fri, Jul 28 2023 at 10:42, Jens Axboe wrote:
> s patchset adds support for first futex wake and wait, and then
> futexv.
Can you please just wait until the futex core bits have been agreed on
and merged? No need to contribute more mess in everyones inbox.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-07-31 16:06 ` [PATCHSET v4] Add io_uring futex/futexv support Thomas Gleixner
@ 2023-08-06 16:44 ` Jens Axboe
2023-08-07 1:23 ` Thomas Gleixner
0 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2023-08-06 16:44 UTC (permalink / raw)
To: Thomas Gleixner, io-uring, linux-kernel; +Cc: peterz, andres
On 7/31/23 10:06?AM, Thomas Gleixner wrote:
> On Fri, Jul 28 2023 at 10:42, Jens Axboe wrote:
>> s patchset adds support for first futex wake and wait, and then
>> futexv.
>
> Can you please just wait until the futex core bits have been agreed on
> and merged? No need to contribute more mess in everyones inbox.
Also no need to keep dragging out the review of the other bits. The
dependency is only there so we can use FUTEX2 flags for this - which
does make sense to me, but we should probably split Peter's series in
two as there's no dependency on the functional bits on that patch
series. As we're getting ever closer to the merge window, and I have
other things sitting on top of the futex series, that's problematic for
me.
--
Jens Axboe
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-06 16:44 ` Jens Axboe
@ 2023-08-07 1:23 ` Thomas Gleixner
2023-08-07 18:23 ` Jens Axboe
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Gleixner @ 2023-08-07 1:23 UTC (permalink / raw)
To: Jens Axboe, io-uring, linux-kernel; +Cc: peterz, andres
Jens!
On Sun, Aug 06 2023 at 10:44, Jens Axboe wrote:
> On 7/31/23 10:06?AM, Thomas Gleixner wrote:
>> Can you please just wait until the futex core bits have been agreed on
>> and merged? No need to contribute more mess in everyones inbox.
>
> Also no need to keep dragging out the review of the other bits. The
> dependency is only there so we can use FUTEX2 flags for this - which
> does make sense to me, but we should probably split Peter's series in
> two as there's no dependency on the functional bits on that patch
> series. As we're getting ever closer to the merge window, and I have
> other things sitting on top of the futex series, that's problematic for
> me.
Seriously?
You are still trying to sell me "Features first - corrrectness
later/never"?
Go and look at the amount of fallout this has caused in the last years.
io-urine is definitely the leader of the pack in my [email protected]
inbox.
Vs. the problem at hand. I've failed to catch a major issue with futex
patches in the past and I'm not seeing any reason to rush any of this to
repeat the experience just because.
You know very well that your whatever depends on this series has to wait
until the basics are sorted and there is absolutely no reason that your
so important things have to be rushed into the next merge window.
It surely makes sense to split these things up into independent series,
but _you_ could have done that weeks ago instead of just reposting an
umodified and unreviewed RFC series from Peter and then coming out now
and complaining about the lack of progress.
Sorry no.
Thanks,
tglx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-07 1:23 ` Thomas Gleixner
@ 2023-08-07 18:23 ` Jens Axboe
2023-08-15 0:12 ` Thomas Gleixner
0 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2023-08-07 18:23 UTC (permalink / raw)
To: Thomas Gleixner, io-uring, linux-kernel; +Cc: peterz, andres
On 8/6/23 7:23?PM, Thomas Gleixner wrote:
> Jens!
>
> On Sun, Aug 06 2023 at 10:44, Jens Axboe wrote:
>> On 7/31/23 10:06?AM, Thomas Gleixner wrote:
>>> Can you please just wait until the futex core bits have been agreed on
>>> and merged? No need to contribute more mess in everyones inbox.
>>
>> Also no need to keep dragging out the review of the other bits. The
>> dependency is only there so we can use FUTEX2 flags for this - which
>> does make sense to me, but we should probably split Peter's series in
>> two as there's no dependency on the functional bits on that patch
>> series. As we're getting ever closer to the merge window, and I have
>> other things sitting on top of the futex series, that's problematic for
>> me.
>
> Seriously?
>
> You are still trying to sell me "Features first - corrrectness
> later/never"?
That's not what I'm saying at all. I wrote these patches 3 months ago,
and like I mentioned, I think doing the futex2 flags for that side is a
good suggestion from Peter. As those initial prep patches are all these
require, rather than the full futex2 series, there's no reason not to
review these at the same time too, if people should be so inclined.
> Go and look at the amount of fallout this has caused in the last years.
> io-urine is definitely the leader of the pack in my [email protected]
> inbox.
We're now resorting to name calling? Sorry, but I think that's pretty
low and not very professional.
> Vs. the problem at hand. I've failed to catch a major issue with futex
> patches in the past and I'm not seeing any reason to rush any of this to
> repeat the experience just because.
I'm not asking anyone to rush anything.
> You know very well that your whatever depends on this series has to wait
> until the basics are sorted and there is absolutely no reason that your
> so important things have to be rushed into the next merge window.
Again, you're making assumptions.
> It surely makes sense to split these things up into independent series,
> but _you_ could have done that weeks ago instead of just reposting an
> umodified and unreviewed RFC series from Peter and then coming out now
> and complaining about the lack of progress.
It's Peter's series, I'm not going to split his series and step on his
toes. I already separately tested, and will do so with the updated
series as well when I get back, since I saw he posted one.
--
Jens Axboe
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 03/12] futex: Flag conversion
2023-07-28 16:42 ` [PATCH 03/12] futex: Flag conversion Jens Axboe
@ 2023-08-09 18:04 ` Gabriel Krisman Bertazi
0 siblings, 0 replies; 22+ messages in thread
From: Gabriel Krisman Bertazi @ 2023-08-09 18:04 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, linux-kernel, peterz, andres, tglx
Jens Axboe <[email protected]> writes:
> From: Peter Zijlstra <[email protected]>
>
> Futex has 3 sets of flags:
>
> - legacy futex op bits
> - futex2 flags
> - internal flags
>
> Add a few helpers to convert from the API flags into the internal
> flags.
>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Signed-off-by: Jens Axboe <[email protected]>
> ---
> kernel/futex/futex.h | 64 +++++++++++++++++++++++++++++++++++++++--
> kernel/futex/syscalls.c | 24 ++++++----------
> kernel/futex/waitwake.c | 4 +--
> 3 files changed, 72 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h
> index b5379c0e6d6d..c0e04599904a 100644
> --- a/kernel/futex/futex.h
> +++ b/kernel/futex/futex.h
> @@ -5,6 +5,7 @@
> #include <linux/futex.h>
> #include <linux/rtmutex.h>
> #include <linux/sched/wake_q.h>
> +#include <linux/compat.h>
>
> #ifdef CONFIG_PREEMPT_RT
> #include <linux/rcuwait.h>
> @@ -16,8 +17,15 @@
> * Futex flags used to encode options to functions and preserve them across
> * restarts.
> */
> +#define FLAGS_SIZE_8 0x00
> +#define FLAGS_SIZE_16 0x01
> +#define FLAGS_SIZE_32 0x02
> +#define FLAGS_SIZE_64 0x03
> +
> +#define FLAGS_SIZE_MASK 0x03
> +
> #ifdef CONFIG_MMU
> -# define FLAGS_SHARED 0x01
> +# define FLAGS_SHARED 0x10
> #else
> /*
> * NOMMU does not have per process address space. Let the compiler optimize
> @@ -25,8 +33,58 @@
> */
> # define FLAGS_SHARED 0x00
> #endif
> -#define FLAGS_CLOCKRT 0x02
> -#define FLAGS_HAS_TIMEOUT 0x04
> +#define FLAGS_CLOCKRT 0x20
> +#define FLAGS_HAS_TIMEOUT 0x40
> +#define FLAGS_NUMA 0x80
> +
> +/* FUTEX_ to FLAGS_ */
> +static inline unsigned int futex_to_flags(unsigned int op)
> +{
> + unsigned int flags = FLAGS_SIZE_32;
> +
> + if (!(op & FUTEX_PRIVATE_FLAG))
> + flags |= FLAGS_SHARED;
> +
> + if (op & FUTEX_CLOCK_REALTIME)
> + flags |= FLAGS_CLOCKRT;
> +
> + return flags;
> +}
> +
> +/* FUTEX2_ to FLAGS_ */
> +static inline unsigned int futex2_to_flags(unsigned int flags2)
> +{
> + unsigned int flags = flags2 & FUTEX2_64;
FUTEX2_64 -> FLAGS_SIZE_MASK
> +
> + if (!(flags2 & FUTEX2_PRIVATE))
> + flags |= FLAGS_SHARED;
> +
> + if (flags2 & FUTEX2_NUMA)
> + flags |= FLAGS_NUMA;
> +
> + return flags;
> +}
> +
> +static inline bool futex_flags_valid(unsigned int flags)
> +{
> + /* Only 64bit futexes for 64bit code */
> + if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) {
> + if ((flags & FLAGS_SIZE_MASK) == FLAGS_SIZE_64)
> + return false;
> + }
I read the comment above as '64bit code can only have 64bit futexes',
which is obviously wrong and not what the code is checking.
Something like this would be better:
/* Reject 64bit futexes on !64bit code. */
Or Perhaps make it generic:
/* Don't allow futexes larger than the word size */
if (futex_size(flags) > (__WORDSIZE/8) || in_compat_syscall())
--
Gabriel Krisman Bertazi
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-07 18:23 ` Jens Axboe
@ 2023-08-15 0:12 ` Thomas Gleixner
2023-08-15 0:18 ` Jens Axboe
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Gleixner @ 2023-08-15 0:12 UTC (permalink / raw)
To: Jens Axboe, io-uring, linux-kernel; +Cc: peterz, andres
Jens!
On Mon, Aug 07 2023 at 12:23, Jens Axboe wrote:
> On 8/6/23 7:23?PM, Thomas Gleixner wrote:
>> Go and look at the amount of fallout this has caused in the last years.
>> io-urine is definitely the leader of the pack in my [email protected]
>> inbox.
>
> We're now resorting to name calling? Sorry, but I think that's pretty
> low and not very professional.
I'm not resorting to that. If you got offended by the meme which
happened to elapse into my reply, then I can definitely understand
that. That was not my intention at all. But you might think about why
that meme exists in the first place.
>> Vs. the problem at hand. I've failed to catch a major issue with futex
>> patches in the past and I'm not seeing any reason to rush any of this to
>> repeat the experience just because.
>
> I'm not asking anyone to rush anything.
"As we're getting ever closer to the merge window, and I have other
things sitting on top of the futex series, that's problematic for me."
That's your words and how should I pretty please interpret them
correctly?
Thanks,
tglx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-15 0:12 ` Thomas Gleixner
@ 2023-08-15 0:18 ` Jens Axboe
2023-08-15 0:47 ` Thomas Gleixner
0 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2023-08-15 0:18 UTC (permalink / raw)
To: Thomas Gleixner, io-uring, linux-kernel; +Cc: peterz, andres
On 8/14/23 6:12 PM, Thomas Gleixner wrote:
> Jens!
>
> On Mon, Aug 07 2023 at 12:23, Jens Axboe wrote:
>> On 8/6/23 7:23?PM, Thomas Gleixner wrote:
>>> Go and look at the amount of fallout this has caused in the last years.
>>> io-urine is definitely the leader of the pack in my [email protected]
>>> inbox.
>>
>> We're now resorting to name calling? Sorry, but I think that's pretty
>> low and not very professional.
>
> I'm not resorting to that. If you got offended by the meme which
> happened to elapse into my reply, then I can definitely understand
> that. That was not my intention at all. But you might think about why
> that meme exists in the first place.
It's been there since day 1 because a) the spelling is close, and b)
some people are just childish. Same reason kids in the 3rd grade come up
with nicknames for each others. And that's fine, but most people grow
out of that, and it certainly has no place in what is supposedly a
professional setting.
>>> Vs. the problem at hand. I've failed to catch a major issue with futex
>>> patches in the past and I'm not seeing any reason to rush any of this to
>>> repeat the experience just because.
>>
>> I'm not asking anyone to rush anything.
>
> "As we're getting ever closer to the merge window, and I have other
> things sitting on top of the futex series, that's problematic for me."
>
> That's your words and how should I pretty please interpret them
> correctly?
Do I need to reorder them? And clearly looks like the answer is yes,
which is fine.
--
Jens Axboe
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-15 0:18 ` Jens Axboe
@ 2023-08-15 0:47 ` Thomas Gleixner
2023-08-15 1:51 ` Jens Axboe
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Gleixner @ 2023-08-15 0:47 UTC (permalink / raw)
To: Jens Axboe, io-uring, linux-kernel; +Cc: peterz, andres
On Mon, Aug 14 2023 at 18:18, Jens Axboe wrote:
> On 8/14/23 6:12 PM, Thomas Gleixner wrote:
>>> We're now resorting to name calling? Sorry, but I think that's pretty
>>> low and not very professional.
>>
>> I'm not resorting to that. If you got offended by the meme which
>> happened to elapse into my reply, then I can definitely understand
>> that. That was not my intention at all. But you might think about why
>> that meme exists in the first place.
>
> It's been there since day 1 because a) the spelling is close, and b)
> some people are just childish. Same reason kids in the 3rd grade come up
> with nicknames for each others. And that's fine, but most people grow
> out of that, and it certainly has no place in what is supposedly a
> professional setting.
Sure. Repeat that as often you want. I already made clear in my reply
that this was unintentional, no?
Though the fact that this "rush the feature" ends up in my security
inbox more than justified has absolutely nothing to do with my
potentially childish and non-professionl attitude, right?
Though you gracefully ignored that. Fair enough...
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCHSET v4] Add io_uring futex/futexv support
2023-08-15 0:47 ` Thomas Gleixner
@ 2023-08-15 1:51 ` Jens Axboe
0 siblings, 0 replies; 22+ messages in thread
From: Jens Axboe @ 2023-08-15 1:51 UTC (permalink / raw)
To: Thomas Gleixner, io-uring, linux-kernel; +Cc: peterz, andres
On 8/14/23 6:47 PM, Thomas Gleixner wrote:
> On Mon, Aug 14 2023 at 18:18, Jens Axboe wrote:
>> On 8/14/23 6:12 PM, Thomas Gleixner wrote:
>
>>>> We're now resorting to name calling? Sorry, but I think that's pretty
>>>> low and not very professional.
>>>
>>> I'm not resorting to that. If you got offended by the meme which
>>> happened to elapse into my reply, then I can definitely understand
>>> that. That was not my intention at all. But you might think about why
>>> that meme exists in the first place.
>>
>> It's been there since day 1 because a) the spelling is close, and b)
>> some people are just childish. Same reason kids in the 3rd grade come up
>> with nicknames for each others. And that's fine, but most people grow
>> out of that, and it certainly has no place in what is supposedly a
>> professional setting.
>
> Sure. Repeat that as often you want. I already made clear in my reply
> that this was unintentional, no?
Wasn't clear to me, and your repeated undertones don't help either.
> Though the fact that this "rush the feature" ends up in my security
> inbox more than justified has absolutely nothing to do with my
> potentially childish and non-professionl attitude, right?
I've already made it clear that nothing is being rushed, yet you keep
harping on that. It was in my reply, again, though you gracefully
ignored that, again.
Have we had security issues? For sure, and more than I would've liked.
By far most of that is for old kernels, not the current code base. We've
made good progress getting that migrated back, and it's always top of
the mind when developing new features. If you think I don't take this
seriously, then you are ignorant, and suggesting otherwise is slander.
And since it's apparently a big problem in your inbox, you will have
undoubtedly also seen that we've always been handling these well and
expediently.
--
Jens Axboe
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2023-08-15 1:52 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-28 16:42 [PATCHSET v4] Add io_uring futex/futexv support Jens Axboe
2023-07-28 16:42 ` [PATCH 01/12] futex: Clarify FUTEX2 flags Jens Axboe
2023-07-28 16:42 ` [PATCH 02/12] futex: Extend the " Jens Axboe
2023-07-28 16:42 ` [PATCH 03/12] futex: Flag conversion Jens Axboe
2023-08-09 18:04 ` Gabriel Krisman Bertazi
2023-07-28 16:42 ` [PATCH 04/12] futex: Validate futex value against futex size Jens Axboe
2023-07-28 16:42 ` [PATCH 05/12] futex: move FUTEX2_MASK to futex.h Jens Axboe
2023-07-28 16:42 ` [PATCH 06/12] futex: factor out the futex wake handling Jens Axboe
2023-07-28 16:42 ` [PATCH 07/12] futex: abstract out a __futex_wake_mark() helper Jens Axboe
2023-07-28 16:42 ` [PATCH 08/12] io_uring: add support for futex wake and wait Jens Axboe
2023-07-28 16:42 ` [PATCH 09/12] futex: add wake_data to struct futex_q Jens Axboe
2023-07-28 16:42 ` [PATCH 10/12] futex: make futex_parse_waitv() available as a helper Jens Axboe
2023-07-28 16:42 ` [PATCH 11/12] futex: make the vectored futex operations available Jens Axboe
2023-07-28 16:42 ` [PATCH 12/12] io_uring: add support for vectored futex waits Jens Axboe
2023-07-31 16:06 ` [PATCHSET v4] Add io_uring futex/futexv support Thomas Gleixner
2023-08-06 16:44 ` Jens Axboe
2023-08-07 1:23 ` Thomas Gleixner
2023-08-07 18:23 ` Jens Axboe
2023-08-15 0:12 ` Thomas Gleixner
2023-08-15 0:18 ` Jens Axboe
2023-08-15 0:47 ` Thomas Gleixner
2023-08-15 1:51 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox