Re: [PATCH V3 05/12] io_uring: bpf: extend io_uring with bpf struct_ops

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

On Fri, Apr 03, 2026 at 09:44:03AM -0600, Jens Axboe wrote:
> On 4/2/26 10:05 PM, Ming Lei wrote:
> > On Wed, Mar 25, 2026 at 07:49:22PM -0600, Jens Axboe wrote:
> >> On 3/24/26 10:37 AM, Ming Lei wrote:
> >>> @@ -493,7 +494,16 @@ struct io_ring_ctx {
> >>>  	DECLARE_HASHTABLE(napi_ht, 4);
> >>>  #endif
> >>>  
> >>> -	struct io_uring_bpf_ops		*bpf_ops;
> >>> +	/*
> >>> +	 * bpf_ops and bpf_ext_ops are mutually exclusive: bpf_ops is used
> >>> +	 * for io_uring_bpf_ops struct_ops, while bpf_ext_ops provides
> >>> +	 * per-opcode BPF extension operations (IORING_SETUP_BPF_EXT).
> >>> +	 * The two cannot be active at the same time on the same ring.
> >>> +	 */
> >>> +	union {
> >>> +		struct io_uring_bpf_ops		*bpf_ops;
> >>> +		struct uring_bpf_ops_kern	*bpf_ext_ops;
> >>> +	};
> >>
> >> What am I missing here, why is this the case? What makes the use of both
> >> at the same time impossible?
> > 
> > Please see the following code:
> > 
> > static inline bool io_has_loop_ops(struct io_ring_ctx *ctx)
> > {
> >         return data_race(ctx->loop_step);
> > }
> > 
> > io_uring_enter():
> > 	...
> > 	if (io_has_loop_ops(ctx)) {
> > 		ret = io_run_loop(ctx);
> > 		goto out;
> > 	}
> > 	...
> > 
> > So if ->loop_step is assigned from io_install_bpf() called from bpf_ops
> > registration, traditional userspace SQE submission and CQE reap are
> > bypassed completely, then IORING_OP_BPF and any other OP can't be handled
> > at all.
> 
> It ends up calling io_submit_sqes() all the same, so not sure I follow the
> problem here. Seems to me that the only thing that is making it mutually
> exclusive is the fact that you unionized the ops.

Looks I miss the point, will switch to non-exclusive in next version.

Thanks,
Ming