BPF controlled io_uring

io_uring/bpf.h new file +14 -0

new file mode 100644
index 000000000000..a61c489d306b
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef IOU_BPF_H
+#define IOU_BPF_H
+
+#include <linux/io_uring_types.h>
+#include <linux/bpf.h>
+
+#include "io_uring.h"
+
+struct io_uring_ops {
+};
+
+static inline bool io_bpf_attached(struct io_ring_ctx *ctx)
+{

Quoted 20 lines · Pavel Begunkov

io_uring/bpf.h new file +14 -0

new file mode 100644
index 000000000000..a61c489d306b
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef IOU_BPF_H
+#define IOU_BPF_H
+
+#include <linux/io_uring_types.h>
+#include <linux/bpf.h>
+
+#include "io_uring.h"
+
+struct io_uring_ops {
+};
+
+static inline bool io_bpf_attached(struct io_ring_ctx *ctx)
+{

io_uring/bpf.h line 24

Quoted 10 lines

io_uring/bpf.h new file +10 -0

+	return IS_ENABLED(CONFIG_BPF) && ctx->bpf_ops != NULL;
+}
+
+#ifdef CONFIG_BPF
+void io_unregister_bpf_ops(struct io_ring_ctx *ctx);
+#else
+static inline void io_unregister_bpf_ops(struct io_ring_ctx *ctx)
+{
+}
+#endif

Should be

#ifdef IO_URING_BPF

here.

Add ring_fd to the struct_ops and implement [un]registration.

Signed-off-by Pavel Begunkov <[email protected]>

---
 io_uring/bpf.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++-
 io_uring/bpf.h |  3 +++
 2 files changed, 69 insertions(+), 1 deletion(-)

io_uring/bpf.c +2 -0

index 3096c54e4fb3..0f82acf09959 100644
@@ -3,6 +3,8 @@
 #include "bpf.h"
 #include "register.h"
 
+DEFINE_MUTEX(io_bpf_ctrl_mutex);
+
 static struct io_uring_ops io_bpf_ops_stubs = {
 };
 

@@ -50,20 +52,83 @@ static int bpf_io_init_member(const struct btf_type *t,
 			       const struct btf_member *member,
 			       void *kdata, const void *udata)
 {

Quoted 8 lines

const struct btf_member *member, void *kdata, const void *udata)
{

io_uring/bpf.c +5 -0

+	u32 moff = __btf_member_bit_offset(t, member) / 8;
+	const struct io_uring_ops *uops = udata;
+	struct io_uring_ops *ops = kdata;
+
+	switch (moff) {

io_uring/bpf.c static int bpf_io_init_member(const struct btf_type *t, · line 64

Quoted 5 lines

io_uring/bpf.c +5 -0

+	case offsetof(struct io_uring_ops, ring_fd):
+		ops->ring_fd = uops->ring_fd;
+		return 1;
+	}
+	return 0;

Possible to pass in here whether the ring fd is registered or not? Such that it can be used in bpf_io_reg() as well.

Quoted 7 lines

io_uring/bpf.c +7 -0

+static int io_register_bpf_ops(struct io_ring_ctx *ctx, struct io_uring_ops *ops)
+{
+	if (ctx->bpf_ops)
+		return -EBUSY;
+	if (!(ctx->flags & IORING_SETUP_DEFER_TASKRUN))
+		return -EOPNOTSUPP;
+

io_uring/bpf.c static int bpf_io_init_member(const struct btf_type *t, · line 78

Quoted 5 lines

io_uring/bpf.c +3 -0

+	percpu_ref_get(&ctx->refs);
+	ops->ctx = ctx;
+	ctx->bpf_ops = ops;
  	return 0;
  }

Haven't looked too deeply yet, but what's the dependency with DEFER_TASKRUN?

On 6/6/25 15:57, Jens Axboe wrote:
...>> @@ -50,20 +52,83 @@ static int bpf_io_init_member(const struct btf_type *t,

Quoted 14 lines

io_uring/bpf.c static int bpf_io_init_member(const struct btf_type *t, · line 64

Quoted 13 lines

const struct btf_member *member, void *kdata, const void *udata)
{

io_uring/bpf.c +10 -0

+    u32 moff = __btf_member_bit_offset(t, member) / 8;
+    const struct io_uring_ops *uops = udata;
+    struct io_uring_ops *ops = kdata;
+
+    switch (moff) {
+    case offsetof(struct io_uring_ops, ring_fd):
+        ops->ring_fd = uops->ring_fd;
+        return 1;
+    }
+    return 0;

Quoted 2 lines

Possible to pass in here whether the ring fd is registered or not? Such that it can be used in bpf_io_reg() as well.

That requires registration to be done off the syscall path (e.g. no workers), which is low risk and I'm pretty sure that's how it's done, but in either case that's not up to io_uring and should be vetted by bpf. It's not important to performance, and leaking that to other syscalls is a bad idea as well, so in the meantime it's just left unsupported.

Quoted 7 lines

Quoted 7 lines

io_uring/bpf.c +7 -0

+static int io_register_bpf_ops(struct io_ring_ctx *ctx, struct io_uring_ops *ops)
+{
+    if (ctx->bpf_ops)
+        return -EBUSY;
+    if (!(ctx->flags & IORING_SETUP_DEFER_TASKRUN))
+        return -EOPNOTSUPP;
+

Quoted 8 lines

io_uring/bpf.c static int bpf_io_init_member(const struct btf_type *t, · line 78

Quoted 5 lines

io_uring/bpf.c +3 -0

+    percpu_ref_get(&ctx->refs);
+    ops->ctx = ctx;
+    ctx->bpf_ops = ops;
      return 0;
  }

Haven't looked too deeply yet, but what's the dependency with DEFER_TASKRUN?

Unregistration needs to be sync'ed with waiters, and that can easily become a problem. Taking the lock like in this set in not necessarily the right solution. I plan to wait and see where it goes rather than shooting myself in the leg right away.

io_uring/bpf.h line 30

Quoted 9 lines · Pavel Begunkov

io_uring/bpf.h +8 -0

+static inline int io_run_bpf(struct io_ring_ctx *ctx, struct iou_loop_state *state)
+{
+       scoped_guard(mutex, &ctx->uring_lock) {
+               if (!ctx->bpf_ops)
+                       return IOU_EVENTS_STOP;
+               return ctx->bpf_ops->handle_events(ctx, state);
+       }
+}

you're grabbing the mutex before calling bpf prog and doing it in a loop million times a second?
Looks like massive overhead for program invocation. I'm surprised it's fast.

io_uring/bpf.h line 30

Quoted 9 lines · On Fri, Jun 6, 2025 at 6:58?AM Pavel Begunkov <[email protected]> wrote:

io_uring/bpf.h +8 -0

+static inline int io_run_bpf(struct io_ring_ctx *ctx, struct iou_loop_state *state)
+{
+       scoped_guard(mutex, &ctx->uring_lock) {
+               if (!ctx->bpf_ops)
+                       return IOU_EVENTS_STOP;
+               return ctx->bpf_ops->handle_events(ctx, state);
+       }
+}

you're grabbing the mutex before calling bpf prog and doing it in a loop million times a second?
Looks like massive overhead for program invocation. I'm surprised it's fast.

A handle_events program should be able to parse the CQ and submit new requests, add kfuncs to cover that. The only essential kfunc here is bpf_io_uring_submit_sqes, and the rest are likely be removed in a non-RFC version in favour of a more general approach.

Signed-off-by Pavel Begunkov <[email protected]>

---
 io_uring/bpf.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

io_uring/bpf.c +64 -0

index f86b12f280e8..9494e4289605 100644
@@ -1,12 +1,92 @@
 #include <linux/mutex.h>
 #include <linux/bpf_verifier.h>
 
+#include "io_uring.h"
 #include "bpf.h"
 #include "register.h"
 
 static const struct btf_type *loop_state_type;
 DEFINE_MUTEX(io_bpf_ctrl_mutex);
 
+__bpf_kfunc_start_defs();
+
+__bpf_kfunc int bpf_io_uring_submit_sqes(struct io_ring_ctx *ctx,
+                                        unsigned nr)
+{
+       return io_submit_sqes(ctx, nr);
+}
+
+__bpf_kfunc int bpf_io_uring_post_cqe(struct io_ring_ctx *ctx,
+                                     u64 data, u32 res, u32 cflags)
+{
+       bool posted;
+
+       posted = io_post_aux_cqe(ctx, data, res, cflags);
+       return posted ? 0 : -ENOMEM;
+}
+
+__bpf_kfunc int bpf_io_uring_queue_sqe(struct io_ring_ctx *ctx,
+                                       void *bpf_sqe, int mem__sz)
+{
+       unsigned tail = ctx->rings->sq.tail;
+       struct io_uring_sqe *sqe;
+
+       if (mem__sz != sizeof(*sqe))
+               return -EINVAL;
+
+       ctx->rings->sq.tail++;
+       tail &= (ctx->sq_entries - 1);
+       /* double index for 128-byte SQEs, twice as long */
+       if (ctx->flags & IORING_SETUP_SQE128)
+               tail <<= 1;
+       sqe = &ctx->sq_sqes[tail];
+       memcpy(sqe, bpf_sqe, sizeof(*sqe));
+       return 0;
+}
+
+__bpf_kfunc
+struct io_uring_cqe *bpf_io_uring_get_cqe(struct io_ring_ctx *ctx, u32 idx)
+{
+       unsigned max_entries = ctx->cq_entries;
+       struct io_uring_cqe *cqe_array = ctx->rings->cqes;
+
+       if (ctx->flags & IORING_SETUP_CQE32)
+               max_entries *= 2;
+       return &cqe_array[idx & (max_entries - 1)];
+}
+
+__bpf_kfunc
+struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx)
+{
+       struct io_rings *rings = ctx->rings;
+       unsigned int mask = ctx->cq_entries - 1;
+       unsigned head = rings->cq.head;
+       struct io_uring_cqe *cqe;
+
+       /* TODO CQE32 */
+       if (head == rings->cq.tail)
+               return NULL;
+
+       cqe = &rings->cqes[head & mask];
+       rings->cq.head++;
+       return cqe;
+}

On Fri, Jun 6, 2025 at 6:58 AM Pavel Begunkov <[email protected]> wrote:

Quoted 24 lines

(quoted diff) +24 -0

+struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx)
+{
+       struct io_rings *rings = ctx->rings;
+       unsigned int mask = ctx->cq_entries - 1;
+       unsigned head = rings->cq.head;
+       struct io_uring_cqe *cqe;
+
+       /* TODO CQE32 */
+       if (head == rings->cq.tail)
+               return NULL;
+
+       cqe = &rings->cqes[head & mask];
+       rings->cq.head++;
+       return cqe;
+}
+
+__bpf_kfunc_end_defs();
+
+BTF_KFUNCS_START(io_uring_kfunc_set)
+BTF_ID_FLAGS(func, bpf_io_uring_submit_sqes, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_post_cqe, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_queue_sqe, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_get_cqe, 0);
+BTF_ID_FLAGS(func, bpf_io_uring_extract_next_cqe, KF_RET_NULL);

Quoted 1 line

+BTF_KFUNCS_END(io_uring_kfunc_set)

This is not safe in general.
The verifier doesn't enforce argument safety here.
As a minimum you need to add KF_TRUSTED_ARGS flag to all kfunc. And once you do that you'll see that the verifier doesn't recognize the cqe returned from bpf_io_uring_get_cqe*() as trusted.

Looking at your example:
https://github.com/axboe/liburing/commit/706237127f03e15b4cc9c7c31c16d34dbff37cdc
it doesn't care about contents of cqe and doesn't pass it further. So sort-of ok-ish right now,
but if you need to pass cqe to another kfunc
you would need to add an open coded iterator for cqe-s with appropriate KF_ITER* flags
or maybe add acquire/release semantics for cqe.
Like, get_cqe will be KF_ACQUIRE, and you'd need matching KF_RELEASE kfunc,

so that 'cqe' is not lost.
Then 'cqe' will be trusted and you can pass it as actual 'cqe' into another kfunc.
Without KF_ACQUIRE the verifier sees that get_cqe*() kfuncs return 'struct io_uring_cqe *' and it's ok for tracing or passing into kfuncs like bpf_io_uring_queue_sqe() that don't care about a particular type,
but not ok for full tracking of objects.

For next revision please post all selftest, examples, and bpf progs on the list,
so people don't need to search github.

Quoted 3 lines

For next revision please post all selftest, examples, and bpf progs on the list,
so people don't need to search github.

Did the link in the cover letter not work for you? I'm confused since it's all in a branch in my tree, but you linked to the same patches but in Jens' tree, and I have zero clue what they're doing there or how you found them.

Quoted 1 line · Alexei Starovoitov

On Fri, Jun 6, 2025 at 6:58 AM Pavel Begunkov <[email protected]> wrote:

...>> +__bpf_kfunc

Quoted 24 lines

Quoted 24 lines

(quoted diff) +24 -0

+struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx)
+{
+       struct io_rings *rings = ctx->rings;
+       unsigned int mask = ctx->cq_entries - 1;
+       unsigned head = rings->cq.head;
+       struct io_uring_cqe *cqe;
+
+       /* TODO CQE32 */
+       if (head == rings->cq.tail)
+               return NULL;
+
+       cqe = &rings->cqes[head & mask];
+       rings->cq.head++;
+       return cqe;
+}
+
+__bpf_kfunc_end_defs();
+
+BTF_KFUNCS_START(io_uring_kfunc_set)
+BTF_ID_FLAGS(func, bpf_io_uring_submit_sqes, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_post_cqe, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_queue_sqe, KF_SLEEPABLE);
+BTF_ID_FLAGS(func, bpf_io_uring_get_cqe, 0);
+BTF_ID_FLAGS(func, bpf_io_uring_extract_next_cqe, KF_RET_NULL);

Quoted 8 lines

Quoted 1 line

+BTF_KFUNCS_END(io_uring_kfunc_set)

This is not safe in general.
The verifier doesn't enforce argument safety here.
As a minimum you need to add KF_TRUSTED_ARGS flag to all kfunc. And once you do that you'll see that the verifier doesn't recognize the cqe returned from bpf_io_uring_get_cqe*() as trusted.

Thanks, will add it. If I read it right, without the flag the program can, for example, create a struct io_ring_ctx on stack, fill it with nonsense and pass to kfuncs. Is that right?

Quoted 10 lines

Looking at your example:
https://github.com/axboe/liburing/commit/706237127f03e15b4cc9c7c31c16d34dbff37cdc
it doesn't care about contents of cqe and doesn't pass it further. So sort-of ok-ish right now,
but if you need to pass cqe to another kfunc
you would need to add an open coded iterator for cqe-s with appropriate KF_ITER* flags
or maybe add acquire/release semantics for cqe.
Like, get_cqe will be KF_ACQUIRE, and you'd need matching KF_RELEASE kfunc,

Quoted 8 lines

so that 'cqe' is not lost.
Then 'cqe' will be trusted and you can pass it as actual 'cqe' into another kfunc.
Without KF_ACQUIRE the verifier sees that get_cqe*() kfuncs return 'struct io_uring_cqe *' and it's ok for tracing or passing into kfuncs like bpf_io_uring_queue_sqe() that don't care about a particular type,
but not ok for full tracking of objects.

I don't need type safety for SQEs / CQEs, they're supposed to be simple memory blobs containing userspace data only. SQ / CQ are shared with userspace, and the kfuncs can leak the content of passed CQE / SQE to userspace. But I'd like to find a way to reject programs stashing kernel pointers / data into them.

BPF_PROG(name, struct io_ring_ctx *io_ring)

{
     struct io_uring_sqe *cqe = ...;
     cqe->user_data = io_ring;
     cqe->res = io_ring->private_field;
}

And I mentioned in the message, I rather want to get rid of half of the kfuncs, and give BPF direct access to the SQ/CQ instead. Schematically it should look like this:

BPF_PROG(name, struct io_ring_ctx *ring)

{
     struct io_uring_sqe *sqes = get_SQ(ring);

     sqes[ring->sq_tail]->opcode = OP_NOP;
     bpf_kfunc_submit_sqes(ring, 1);

     struct io_uring_cqe *cqes = get_CQ(ring);
     print_cqe(&cqes[ring->cq_head]);
}

I hacked up RET_PTR_TO_MEM for kfuncs, the diff is below, but it'd be great to get rid of the constness of the size argument. I need to digest arenas first as conceptually they look very close.

Quoted 4 lines

For next revision please post all selftest, examples, and bpf progs on the list,
so people don't need to search github.

Did the link in the cover letter not work for you? I'm confused since it's all in a branch in my tree, but you linked to the same patches but in Jens' tree, and I have zero clue what they're doing there or how you found them.

io_uring/bpf.c +1 -0

index 9494e4289605..400a06a74b5d 100644
@@ -2,6 +2,7 @@
  #include <linux/bpf_verifier.h>
 
  #include "io_uring.h"
+#include "memmap.h"
  #include "bpf.h"
  #include "register.h"
 

On Thu, Jun 12, 2025 at 6:25 AM Pavel Begunkov <[email protected]> wrote:

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

+BTF_KFUNCS_END(io_uring_kfunc_set)

This is not safe in general.
The verifier doesn't enforce argument safety here.
As a minimum you need to add KF_TRUSTED_ARGS flag to all kfunc. And once you do that you'll see that the verifier doesn't recognize the cqe returned from bpf_io_uring_get_cqe*() as trusted.

Quoted 3 lines

Thanks, will add it. If I read it right, without the flag the program can, for example, create a struct io_ring_ctx on stack, fill it with nonsense and pass to kfuncs. Is that right?

No. The verifier will only allow a pointer to struct io_ring_ctx to be passed, but it may not be fully trusted.

The verifier has 3 types of pointers to kernel structures:
1. ptr_to_btf_id
2. ptr_to_btf_id | trusted
3. ptr_to_btf_id | untrusted

1st was added long ago for tracing and gradually got adopted for non-tracing needs, but it has a foot gun, since all pointer walks keep ptr_to_btf_id type.
It's fine in some cases to follow pointers, but not in all. Hence 2nd variant was added and there
foo->bar dereference needs to be explicitly allowed instead of allowed by default like for 1st kind.

All loads through 1 and 3 are implemented as probe_read_kernel. while loads from 2 are direct loads.

So kfuncs without KF_TRUSTED_ARGS with struct io_ring_ctx *ctx argument are likely fine and safe, since it's impossible to get this io_ring_ctx pointer by dereferencing some other pointer. But better to tighten safety from the start.
We recommend KF_TRUSTED_ARGS for all kfuncs and eventually it will be the default.

Quoted 15 lines

index 9494e4289605..400a06a74b5d 100644

io_uring/bpf.c +1 -0

@@ -2,6 +2,7 @@
   #include <linux/bpf_verifier.h>
 
   #include "io_uring.h"
+#include "memmap.h"
   #include "bpf.h"
   #include "register.h"
 

@@ -72,6 +73,14 @@ struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx)
         return cqe;
   }
 

io_uring/bpf.c struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx) · line 82

Quoted 7 lines

io_uring/bpf.c +7 -0

+__bpf_kfunc
+void *bpf_io_uring_get_region(struct io_ring_ctx *ctx, u64 size__retsz)
+{
+       if (size__retsz > ((u64)ctx->ring_region.nr_pages << PAGE_SHIFT))
+               return NULL;
+       return io_region_get_ptr(&ctx->ring_region);
+}

and bpf prog should be able to read/write anything in [ctx->ring_region->ptr, ..ptr + size] region ?

Populating (creating) dynptr is probably better.
See bpf_dynptr_from*()

but what is the lifetime of that memory ?

Quoted 1 line · Alexei Starovoitov

On Thu, Jun 12, 2025 at 6:25 AM Pavel Begunkov <[email protected]> wrote:

...>>>> +BTF_ID_FLAGS(func, bpf_io_uring_extract_next_cqe, KF_RET_NULL);

Quoted 32 lines

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

+BTF_KFUNCS_END(io_uring_kfunc_set)

This is not safe in general.
The verifier doesn't enforce argument safety here.
As a minimum you need to add KF_TRUSTED_ARGS flag to all kfunc. And once you do that you'll see that the verifier doesn't recognize the cqe returned from bpf_io_uring_get_cqe*() as trusted.

Quoted 3 lines

Thanks, will add it. If I read it right, without the flag the program can, for example, create a struct io_ring_ctx on stack, fill it with nonsense and pass to kfuncs. Is that right?

No. The verifier will only allow a pointer to struct io_ring_ctx to be passed, but it may not be fully trusted.

The verifier has 3 types of pointers to kernel structures:
1. ptr_to_btf_id
2. ptr_to_btf_id | trusted
3. ptr_to_btf_id | untrusted

1st was added long ago for tracing and gradually got adopted for non-tracing needs, but it has a foot gun, since all pointer walks keep ptr_to_btf_id type.
It's fine in some cases to follow pointers, but not in all. Hence 2nd variant was added and there
foo->bar dereference needs to be explicitly allowed instead of allowed by default like for 1st kind.

All loads through 1 and 3 are implemented as probe_read_kernel. while loads from 2 are direct loads.

Quoted 6 lines

So kfuncs without KF_TRUSTED_ARGS with struct io_ring_ctx *ctx argument are likely fine and safe, since it's impossible to get this io_ring_ctx pointer by dereferencing some other pointer. But better to tighten safety from the start.
We recommend KF_TRUSTED_ARGS for all kfuncs and eventually it will be the default.

Sure, I'll add it, thanks for the explanation

...>> diff --git a/io_uring/bpf.c b/io_uring/bpf.c

Quoted 15 lines

Quoted 15 lines

index 9494e4289605..400a06a74b5d 100644

io_uring/bpf.c +1 -0

@@ -2,6 +2,7 @@
   #include <linux/bpf_verifier.h>
 
   #include "io_uring.h"
+#include "memmap.h"
   #include "bpf.h"
   #include "register.h"
 

@@ -72,6 +73,14 @@ struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx)
         return cqe;
   }
 

Quoted 10 lines

io_uring/bpf.c struct io_uring_cqe *bpf_io_uring_extract_next_cqe(struct io_ring_ctx *ctx) · line 82

Quoted 7 lines

io_uring/bpf.c +7 -0

+__bpf_kfunc
+void *bpf_io_uring_get_region(struct io_ring_ctx *ctx, u64 size__retsz)
+{
+       if (size__retsz > ((u64)ctx->ring_region.nr_pages << PAGE_SHIFT))
+               return NULL;
+       return io_region_get_ptr(&ctx->ring_region);
+}

and bpf prog should be able to read/write anything in [ctx->ring_region->ptr, ..ptr + size] region ?

Right, and it's already rw mmap'ed into the user space.

Quoted 4 lines

Populating (creating) dynptr is probably better.
See bpf_dynptr_from*()

but what is the lifetime of that memory ?

It's valid within a single run of the callback but shouldn't cross into another invocation. Specifically, it's protected by the lock, but that can be tuned. Does that match with what PTR_TO_MEM expects?

I can add refcounting for longer term pinning, maybe to store it as a bpf map or whatever is the right way, but I'd rather avoid anything expensive in the kfunc as that'll likely be called on every program run.

On Fri, Jun 13, 2025 at 9:11 AM Pavel Begunkov <[email protected]> wrote:

Quoted 3 lines

It's valid within a single run of the callback but shouldn't cross into another invocation. Specifically, it's protected by the lock, but that can be tuned. Does that match with what PTR_TO_MEM expects?

yes. PTR_TO_MEM lasts for duration of the prog.

Quoted 4 lines

I can add refcounting for longer term pinning, maybe to store it as a bpf map or whatever is the right way, but I'd rather avoid anything expensive in the kfunc as that'll likely be called on every program run.

yeah. let's not add any refcounting.

It sounds like you want something similar to
__bpf_kfunc __u8 *
hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr_buf_size)

we have a special hack for it already in the verifier. The argument need to be called rdwr_buf_size, then it will be used to establish the range of PTR_TO_MEM. It has to be run-time constant.

What you're proposing with "__retsz" is a cleaner version of the same. But consider bpf_dynptr_from_io_uring(struct io_ring_ctx *ctx) it can create a dynamically sized region,
and later use bpf_dynptr_slice_rdwr() to get writeable chunk of it.

I feel that __retsz approach may actually be a better fit at the end, if you're ok with constant arg.

This series adds io_uring BPF struct_ops, which allows processing events and submitting requests from BPF without returning to user. There is only one callback for now, it's called from the io_uring CQ waiting loop when there is an event to be processed. It also has access to waiting parameters like batching and timeouts.

It's tested with a program that queues a nop request, waits for its completion and then queues another request, repeating it N times. The baseline to compare with is traditional io_uring application doing same without BPF and using 2 requests links, with the same total number of requests.

# ./link 0 100000000
type 2-LINK, requests to run 100000000
sec 20, total (ms) 20374
# ./link 1 100000000
type BPF, requests to run 100000000
sec 13, total (ms) 13700

The BPF version works ~50% faster on a mitigated kernel, while it's not even a completely fair comparison as links are restrictive and can't always be used. Without links the speedup reaches ~80%.