From: David Carlier <devnexen@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>,
Andrea Righi <arighi@nvidia.com>,
Changwoo Min <changwoo@igalia.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org,
David Carlier <devnexen@gmail.com>
Subject: [PATCH] sched_ext: Arm the exit on the sub-scheduler enable error path
Date: Fri, 3 Jul 2026 20:09:57 +0100 [thread overview]
Message-ID: <20260703191002.804763-1-devnexen@gmail.com> (raw)
When enabling a sub-scheduler fails, scx_sub_enable_workfn() jumps to
err_disable and calls scx_flush_disable_work() to unwind. That flush only
does something once the exit has been armed, which happens via
scx_error()/scx_exit(). Several error paths reach err_disable without arming
it - most commonly ops.init_task() rejecting a task with a valid errno, and
the -ENOMEM cases from the arena and cmask scratch allocations.
On those paths teardown never runs: the half-enabled scheduler stays linked
in its parent, ops.exit() is never called, it is left stuck in bypass with
the cgroup subtree still pointing at it, and cmd->ret == 0 reports the attach
as successful. It only gets cleaned up later when the struct_ops map is
detached.
The root enable path already arms the exit before flushing; do the same here.
scx_claim_exit() makes it harmless for paths that already errored.
Signed-off-by: David Carlier <devnexen@gmail.com>
---
kernel/sched/ext/sub.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
index 050420427273..12e2e0787b13 100644
--- a/kernel/sched/ext/sub.c
+++ b/kernel/sched/ext/sub.c
@@ -570,6 +570,17 @@ void scx_sub_enable_workfn(struct kthread_work *work)
percpu_up_write(&scx_fork_rwsem);
err_disable:
mutex_unlock(&scx_enable_mutex);
+ /*
+ * Several error edges reach here without having called scx_error()
+ * (e.g. ops.init_task() returning a valid errno, or -ENOMEM from the
+ * arena/cmask scratch allocation), leaving exit_kind == SCX_EXIT_NONE.
+ * Arm the exit so the disable work is queued; otherwise
+ * scx_flush_disable_work() is a no-op and the half-enabled
+ * sub-scheduler is left linked and reported as a successful attach.
+ * Mirrors scx_root_enable_workfn(); scx_claim_exit() makes this
+ * idempotent for paths that already errored.
+ */
+ scx_error(sch, "scx_sub_enable() failed (%d)", ret);
scx_flush_disable_work(sch);
cmd->ret = 0;
}
--
2.53.0
next reply other threads:[~2026-07-03 19:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 19:09 David Carlier [this message]
2026-07-06 22:14 ` [PATCH] sched_ext: Arm the exit on the sub-scheduler enable error path Tejun Heo
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=20260703191002.804763-1-devnexen@gmail.com \
--to=devnexen@gmail.com \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--cc=tj@kernel.org \
--cc=void@manifault.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.