Re: [PATCH v3 10/10] selftests/io_uring: add bpf io_uring selftests

[Pavel Begunkov <asml.silence@gmail.com>]

On 11/22/25 00:19, Ming Lei wrote:
> On Sat, Nov 22, 2025 at 12:12 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
...
>>>
>>> `thread_fn` is supposed to work concurrently from >1 pthreads:
>>>
>>> 1) io_uring_enter() is claimed as pthread safe
>>>
>>> 2) because of userspace lock protection, there is single code path for
>>> producing sqe for SQ at same time, and single code path for consuming sqe
>>> from io_uring_enter().
>>>
>>> With bpf controlled io_uring patches, sqe can be produced from io_uring_enter(),
>>> and cqe can be consumed in io_uring_enter() too, there will be race between
>>> bpf prog(producing sqe, or consuming cqe) and userspace lock-protected
>>> code block.
>>
>> BPF is attached by the same process/user that creates io_uring. The
>> guarantees are same as before, the user code (which includes BPF)
>> should protect from concurrent mutations.
>>
>> In this example, just extend the first critical section to
>> io_uring_enter(). Concurrent io_uring_enter() will be serialised
>> by a mutex anyway. But let me note, that sharing rings is not
>> a great pattern in either case.
> 
> If io_uring_enter() needs to be serialised, it becomes pthread-unsafe,

The BPF program needs to be synchronised _if_ it races. There are
different ways to sync, including from within the program, but not
racing in the first place is still the preferred option.

> that is why I mentioned this should be documented, because it is one
> very big difference introduced in bpf controlled ring.

That can definitely be mentioned as a guide to users, would be a
diligent thing to do, but my point is that it doesn't change the
contract. SQ/CQ are not protected, and it's the users obligation
to synchronise it. With this set it includes BPF programs the
user attaches.

-- 
Pavel Begunkov