Re: [PATCH] io_uring/bpf-ops: wake up the loop task on eject

[Pavel Begunkov]

On 8/15/26 12:10, Sidong Yang wrote:
> On Sat, Aug 15, 2026 at 11:26:50AM +0100, Pavel Begunkov wrote:
> > On 8/14/26 04:04, Sidong Yang wrote:
> > > io_eject_bpf() clears ctx->loop_step while a loop may be sleeping in
> > > io_loop_wait(), which releases ->uring_lock before schedule(). Nothing
> > > wakes the submitter task after the BPF ops are unregistered through link
> > > destruction or ring teardown, so the task stays blocked in
> > > io_uring_enter() until an unrelated CQE event or signal arrives.
> >
> > If there is nothing to wake it up after bpf removal, it wouldn't
> > be woken up without it either, it's a mess up on the user's
> > side. What's the use case? Especially since you wouldn't
> > normally be removing it from another thread in the current form
> > of the interface.
>
> Fair enough - I found this by reading the code, not from a workload
> that hits it, and I have no use case to justify it. You're right that
> if the CQEs the loop waits for never arrive, it's already broken with
> or without the bpf removal.
>
> Two corrections to my commit message as well. Ring teardown can't
> race: io_unregister_bpf_ops() only runs from io_ring_ctx_free(), and
> the sleeping task holds a ring file reference, so only link destruction
> on another thread can race. And it's a liveness issue only - the task
> sleeps interruptible without ->uring_lock, so the Fixes: tag was too
> strong.
>
> So let's drop this one, unless you think the loop should be stopped
> promptly on eject regardless.

It's preferable indeed. It limits what we can do in the future,
so I'd avoid doing it if there is no use case, and if there is
an application, I'd want to hear about it first as we'll need
other aspects like how it should look like with callback stacking
and so on.

--
Pavel Begunkov