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

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

On Mon, Nov 24, 2025 at 11:57:10AM +0000, Pavel Begunkov wrote:
> 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.

Both the bpf program(kernel) and application(userspace) code may
modify SQ's tail, I don't know how you can sync it within the prog &
application easily, otherwise bpf prog may become quite complicated or
implies safety risk.

> 
> > 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.

bpf prog becomes part of io_uring_enter() which starts to race
with userspace.

The interface needs to be clear from beginning:

- who provides the sync between bpf prog and io_uring application wrt.
  modifying SQ/CQ

- if it is responsibility of bpf prog and application, how to do it?

- otherwise, it is one contract change from syscall pthread safety
viewpoint, because userspace need to serialize io_uring_enter() syscall
with userspace code for manipulating SQ/CQ


Thanks,
Ming