Re: [PATCH v3 07/10] io_uring/bpf: implement struct_ops registration

[Ming Lei <ming.lei@redhat.com>]

On Mon, Nov 24, 2025 at 01:12:29PM +0000, Pavel Begunkov wrote:
> On 11/24/25 03:44, Ming Lei wrote:
> > On Thu, Nov 13, 2025 at 11:59:44AM +0000, Pavel Begunkov wrote:
> > > Add ring_fd to the struct_ops and implement [un]registration.
> ...
> > > +static int io_install_bpf(struct io_ring_ctx *ctx, struct io_uring_ops *ops)
> > > +{
> > > +	if (ctx->bpf_ops)
> > > +		return -EBUSY;
> > > +	ops->priv = ctx;
> > > +	ctx->bpf_ops = ops;
> > > +	ctx->bpf_installed = 1;
> > >   	return 0;
> > >   }
> > >   static int bpf_io_reg(void *kdata, struct bpf_link *link)
> > >   {
> > > -	return -EOPNOTSUPP;
> > > +	struct io_uring_ops *ops = kdata;
> > > +	struct io_ring_ctx *ctx;
> > > +	struct file *file;
> > > +	int ret = -EBUSY;
> > > +
> > > +	file = io_uring_register_get_file(ops->ring_fd, false);
> > > +	if (IS_ERR(file))
> > > +		return PTR_ERR(file);
> > > +	ctx = file->private_data;
> > > +
> > > +	scoped_guard(mutex, &io_bpf_ctrl_mutex) {
> > > +		guard(mutex)(&ctx->uring_lock);
> > > +		ret = io_install_bpf(ctx, ops);
> > > +	}
> > 
> > I feel per-io-uring struct_ops is less useful, because it means the io_uring
> > application has to be capable of loading/registering struct_ops prog, which
> > often needs privilege.
> 
> I gave it a thought before, there would need to be a way to pass a
> program from one (e.g. privileged) task to another, e.g. by putting
> it into a list on attachment from where it can be imported. That
> can be extended, and I needed to start somewhere.

If any task can ask such privileged task to load bpf program for itself,
BPF_UNPRIV_DEFAULT_OFF becomes `N` actually for bpf controlled io_uring.

> 
> > For example of IO link use case you mentioned, why does the application need
> > to get privilege for running IO link?
> 
> Links are there to compare with existing features. It's more interesting
> to allow arbitrary relations / result propagation between requests. Maybe
> some common patterns can be generalised, but otherwise nothing can be
> done with this without custom tailored bpf programs.

I know the motivation, which is one thing covered in my IORING_OP_BPF patch
too.


Thanks,
Ming