From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10DB317B50A for ; Sat, 15 Aug 2026 11:11:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786792262; cv=none; b=G9zgV/wo8f3mzks4nkwxfEE6R9jycCC+DttQKK6MfLWdv6dZUbfTOMpg5znesLQ8xKL+FxGcnG7TVeQVVNiuDL7UJB1MJzoKZ315zOfLgIGlp2WzADbgP0E/dEzJjZxoRDg3BIqoBKu/0NWi98AYl2a90i+Awzp50/AzZ0RtsXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786792262; c=relaxed/simple; bh=o1zSb8nuAVkcmm0EH0JiPyVSy2x70dAJ4ZXp8/MUMbE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kAMXwtoSx70JmWtEN29/1mTH6MxoW5e7ljGKIAPflAqWHcyodjlaCcApI/PraIoGBOXgYcaLVWAkDsbVVONNEGMUnr6zqTR2/Af/0urVJDPshe5nqS9HYVqkWo7mHd5x8VjFlfeSr2SqVIs6+fYUi5kKc/3W8UW2Pc3+4CNEWiE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai; spf=none smtp.mailfrom=furiosa.ai; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b=TSahY/vw; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b="TSahY/vw" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2ceb096e675so22631035ad.0 for ; Sat, 15 Aug 2026 04:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=furiosa.ai; s=google; t=1786792260; x=1787397060; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=cIhGudAOWrm49ZjUgTC2r/gP1J2NjmU3DxbhfPb7SHs=; b=TSahY/vws99RxFYCoPl5KMdJwuhQ/l0+3EmFw9A6UsTrAkfDDnNKE2ZNb8rBUAVxXX J80C7z8obZ2ya9R1lwFeheSEQOSJN+opsGGnjMB6eGMra2GQlIt0zz5YpCxMz/gLHldL LRwbj6eyzmZ/cmaEBeH7zvZCFoef/xJa+iKvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786792260; x=1787397060; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cIhGudAOWrm49ZjUgTC2r/gP1J2NjmU3DxbhfPb7SHs=; b=mBjRJ6Jke7JO/EFvyXq3LvImO7kNWfadaL+QW1zZPIF4BhRUkaRQzDiglu9WEyBeRr rhcu+w5OwUqQ5EndJpZ2aRKDc+E31+eTOvvWeShJ7VphEW7SSvy6NpzChdxRkMFJHSVG 5bDoD/l+qM+taIkOWrdPBEJeZZI/IS8SczdRpK89jvDWpvBYA7OB2B4bnQ9KIs7jVNyy CQPMstRSGb6Gj/Xm6jKsT9sxKyLyutregOEtaN/Ogt+J96c/x3qfmqZoMa4rEi62+tpe 8U5Fey1+zaOKcBQRD/BZCeO21HkF0RpphvsYSWZ+WiuH2a8b75hN/ADxspYb94l61nDS x1iQ== X-Forwarded-Encrypted: i=1; AHgh+RpKA/yYwOxLUfGqddb43gneGAASNK6VwK0at8bsZvCUw/XupJpP2aS2ophwyM14qntsCfyQvhgbS2001rc=@vger.kernel.org X-Gm-Message-State: AOJu0YzNKqqsxJagN/dwbEjdGe+IqrUXGdc0/AT54ZpeLUDKxkyoL7ug HetJ709UuAISaLG3fcwlGKvQVC7sw6+5RY3YojLLjwPRciPBi1ONcIiiaxYq2FeFLRw= X-Gm-Gg: AR+sD10jPB0b8mL/oa0NBKVvJ2dqfXspywsm29h/SlacRWRyROR3uZALoY5GOTed252 5irOGgBFH0DpYcipI+rB+q5061HUrN/C2TPstXTgU9bNmoBKCWgDjgecLat1oaVU2Wy3tz9Zm6v vk5azVZUscSk86HZm3ZrW3kh7x9GMnf4DwISqVQfhs5mJFLg3Sbx3xQXbLYSTg77lFKX/oGuxLA yKmB1M/53v9HRSE994301LuF8hfnvAJ1iU+ZnEyxTvIg5A39ZJ7lphWiB68gF/IEMQajM3z5is6 UBv4vlOu3NLQ8CcqTYip2YMtSyi0+UWCgm9imO3VvBrsiuUmsxHQ71WF/ITp9ey2JDA9aYZfmVG FdeMtiM/pM0DfFD1Fnfb2KoVybrSmayDk4RBgshFeEK60+yfbnwrqWJ1lW42ngjFPRpm/NKGEX+ VepI+Lv53H1S9GJ5n8L6aQwyO/LiFPVaThMglPwyD/SviWV3MNEB4w5AVNzn45pzOLfrdgLzHn/ bcAq2W6cscTotxWivxciyJv X-Received: by 2002:a05:6a20:6a10:b0:3c3:ac5d:b6de with SMTP id adf61e73a8af0-3cc71d55406mr12115358637.22.1786792260388; Sat, 15 Aug 2026 04:11:00 -0700 (PDT) Received: from sidongui-MacBookPro.local ([61.83.209.48]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc095a43327sm1603497a12.28.2026.08.15.04.10.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 04:10:59 -0700 (PDT) Date: Sat, 15 Aug 2026 20:10:43 +0900 From: Sidong Yang To: Pavel Begunkov Cc: io-uring@vger.kernel.org, Jens Axboe , linux-kernel@vger.kernel.org Subject: Re: [PATCH] io_uring/bpf-ops: wake up the loop task on eject Message-ID: References: <20260814030421.61216-1-sidong.yang@furiosa.ai> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 > > --- > > 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 >