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

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe