Sched_ext development
 help / color / mirror / Atom feed
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