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
reply other threads:[~2026-07-03 19:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox