Re: [PATCH 3/5] io_uring: bpf: extend io_uring with bpf struct_ops

[Stefan Metzmacher <metze@samba.org>]

Hi Ming,

> io_uring can be extended with bpf struct_ops in the following ways:
> 
> 1) add new io_uring operation from application
> - one typical use case is for operating device zero-copy buffer, which
> belongs to kernel, and not visible or too expensive to export to
> userspace, such as supporting copy data from this buffer to userspace,
> decompressing data to zero-copy buffer in Android case[1][2], or
> checksum/decrypting.
> 
> [1] https://lpc.events/event/18/contributions/1710/attachments/1440/3070/LPC2024_ublk_zero_copy.pdf
> 
> 2) extend 64 byte SQE, since bpf map can be used to store IO data
>     conveniently
> 
> 3) communicate in IO chain, since bpf map can be shared among IOs,
> when one bpf IO is completed, data can be written to IO chain wide
> bpf map, then the following bpf IO can retrieve the data from this bpf
> map, this way is more flexible than io_uring built-in buffer
> 
> 4) pretty handy to inject error for test purpose
> 
> bpf struct_ops is one very handy way to attach bpf prog with kernel, and
> this patch simply wires existed io_uring operation callbacks with added
> uring bpf struct_ops, so application can define its own uring bpf
> operations.

This sounds useful to me.

> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
>   include/uapi/linux/io_uring.h |   9 ++
>   io_uring/bpf.c                | 271 +++++++++++++++++++++++++++++++++-
>   io_uring/io_uring.c           |   1 +
>   io_uring/io_uring.h           |   3 +-
>   io_uring/uring_bpf.h          |  30 ++++
>   5 files changed, 311 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index b8c49813b4e5..94d2050131ac 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -74,6 +74,7 @@ struct io_uring_sqe {
>   		__u32		install_fd_flags;
>   		__u32		nop_flags;
>   		__u32		pipe_flags;
> +		__u32		bpf_op_flags;
>   	};
>   	__u64	user_data;	/* data to be passed back at completion time */
>   	/* pack this to avoid bogus arm OABI complaints */
> @@ -427,6 +428,13 @@ enum io_uring_op {
>   #define IORING_RECVSEND_BUNDLE		(1U << 4)
>   #define IORING_SEND_VECTORIZED		(1U << 5)
>   
> +/*
> + * sqe->bpf_op_flags		top 8bits is for storing bpf op
> + *				The other 24bits are used for bpf prog
> + */
> +#define IORING_BPF_OP_BITS	(8)
> +#define IORING_BPF_OP_SHIFT	(24)
> +
>   /*
>    * cqe.res for IORING_CQE_F_NOTIF if
>    * IORING_SEND_ZC_REPORT_USAGE was requested
> @@ -631,6 +639,7 @@ struct io_uring_params {
>   #define IORING_FEAT_MIN_TIMEOUT		(1U << 15)
>   #define IORING_FEAT_RW_ATTR		(1U << 16)
>   #define IORING_FEAT_NO_IOWAIT		(1U << 17)
> +#define IORING_FEAT_BPF			(1U << 18)
>   
>   /*
>    * io_uring_register(2) opcodes and arguments
> diff --git a/io_uring/bpf.c b/io_uring/bpf.c
> index bb1e37d1e804..8227be6d5a10 100644
> --- a/io_uring/bpf.c
> +++ b/io_uring/bpf.c
> @@ -4,28 +4,95 @@
>   #include <linux/kernel.h>
>   #include <linux/errno.h>
>   #include <uapi/linux/io_uring.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/bpf_verifier.h>
> +#include <linux/bpf.h>
> +#include <linux/btf.h>
> +#include <linux/btf_ids.h>
> +#include <linux/filter.h>
>   #include "io_uring.h"
>   #include "uring_bpf.h"
>   
> +#define MAX_BPF_OPS_COUNT	(1 << IORING_BPF_OP_BITS)
> +
>   static DEFINE_MUTEX(uring_bpf_ctx_lock);
>   static LIST_HEAD(uring_bpf_ctx_list);
> +DEFINE_STATIC_SRCU(uring_bpf_srcu);
> +static struct uring_bpf_ops bpf_ops[MAX_BPF_OPS_COUNT];

This indicates to me that the whole system with all applications in all namespaces
need to coordinate in order to use these 256 ops?

I think in order to have something useful, this should be per
struct io_ring_ctx and each application should be able to load
its own bpf programs.

Something that uses bpf_prog_get_type() based on a bpf_fd
like SIOCKCMATTACH in net/kcm/kcmsock.c.

metze