From: Sidong Yang <sidong.yang@furiosa.ai>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: io-uring@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] io_uring/bpf-ops: wake up the loop task on eject
Date: Sat, 15 Aug 2026 20:10:43 +0900 [thread overview]
Message-ID: <aoBJMxDWsakOjOp4@sidongui-MacBookPro.local> (raw)
In-Reply-To: <bfb153e0-d3f5-433a-963c-da71c1dc4850@gmail.com>
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.
Thanks,
Sidong
>
> > Since BPF ops require IORING_SETUP_DEFER_TASKRUN, only
> > ctx->submitter_task can run the loop, so wake it directly. The loop
> > rechecks loop_step after waking up and exits with -EFAULT. A spurious
> > wakeup is harmless because io_loop_wait() rechecks the wait condition
> > before sleeping again.
> >
> > Fixes: 98f37634b12b ("io_uring/bpf-ops: implement bpf ops registration")
> > Signed-off-by: Sidong Yang <sidong.yang@furiosa.ai>
> > ---
> > io_uring/bpf-ops.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/io_uring/bpf-ops.c b/io_uring/bpf-ops.c
> > index 5a50f0675fe5..87148dbd3b3e 100644
> > --- a/io_uring/bpf-ops.c
> > +++ b/io_uring/bpf-ops.c
> > @@ -210,6 +210,13 @@ static void io_eject_bpf(struct io_ring_ctx *ctx)
> > ops->priv = NULL;
> > ctx->bpf_ops = NULL;
> > ctx->loop_step = NULL;
> > + /*
> > + * A loop may be sleeping in io_loop_wait() with ->uring_lock
> > + * released. It'll see loop_step == NULL after waking up, but
> > + * nothing wakes it otherwise.
> > + */
> > + if (ctx->submitter_task)
> > + wake_up_state(ctx->submitter_task, TASK_INTERRUPTIBLE);
> > }
> > static void bpf_io_unreg(void *kdata, struct bpf_link *link)
>
> --
> Pavel Begunkov
>
prev parent reply other threads:[~2026-08-15 11:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 3:04 [PATCH] io_uring/bpf-ops: wake up the loop task on eject Sidong Yang
2026-08-14 16:50 ` Gabriel Krisman Bertazi
2026-08-15 10:26 ` Pavel Begunkov
2026-08-15 11:10 ` Sidong Yang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoBJMxDWsakOjOp4@sidongui-MacBookPro.local \
--to=sidong.yang@furiosa.ai \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox