From: Andrea Righi <arighi@nvidia.com>
To: Binbin Deng <18983559317@163.com>
Cc: tj@kernel.org, void@manifault.com, changwoo@igalia.com,
mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kprateek.nayak@amd.com,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v1] sched_ext: finish scheduler init before publishing ops priv
Date: Thu, 15 Oct 2026 18:54:34 +0200 [thread overview]
Message-ID: <atEFSsTO9eT_O9ql@gpd4> (raw)
In-Reply-To: <20261015081431.46628-1-18983559317@163.com>
Hi Binbin,
On Thu, Oct 15, 2026 at 04:14:31PM +0800, Binbin Deng wrote:
> scx_alloc_and_add_sched() assigns ops->priv before initializing the
> scheduler's kobject, list linkage, and sub-scheduler kset, and before
> consuming the BPF arena reference. BPF kfuncs resolve the scheduler with
> scx_prog_sched(), whose readers dereference ops->priv under RCU. Once the
> pointer is published, a program can therefore use fields that the creation
> path has not initialized yet.
>
> Attach a sched_ext struct_ops program that reaches one of those kfuncs
> while registration is still completing. Delay publication until after all
> failure-prone initialization and arena setup have succeeded and
> cmd->arena_map has been transferred to the scheduler.
>
> Found during a static-analysis-assisted audit: candidate sites were
> surfaced by a Coccinelle rule, and the reader/writer paths were
> confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
> not observed at runtime; it is identified by code inspection only.
I don't see any kfunc that can run in this window and access a field that is
still uninitialized. In particular, the sub-scheduler kset is created later,
after either publication point. I also don't see a fallible operation between
the old and new publication points. What failure does this change prevent?
Please always provide a reproducer or a clear, concrete code path to the
reported failure before sending a fix.
Thanks,
-Andrea
>
> Fixes: 105dcd005be2 ("sched_ext: Introduce scx_prog_sched()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Binbin Deng <18983559317@163.com>
> ---
> kernel/sched/ext/ext.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 3219f0da0fe4..bd79bb692cb9 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -7305,13 +7305,6 @@ struct scx_sched *scx_alloc_and_add_sched(struct scx_enable_cmd *cmd,
> INIT_LIST_HEAD(&sch->sibling);
> #endif /* CONFIG_EXT_SUB_SCHED */
>
> - /*
> - * Publishing makes @sch visible to scx_prog_sched() readers. Failure
> - * paths after this point must free @sch through kobject_put() whose
> - * release path defers the actual freeing by an RCU grace period.
> - */
> - rcu_assign_pointer(ops->priv, sch);
> -
> sch->kobj.kset = scx_kset;
> INIT_LIST_HEAD(&sch->all);
>
> @@ -7345,6 +7338,14 @@ struct scx_sched *scx_alloc_and_add_sched(struct scx_enable_cmd *cmd,
> sch->arena_kern_base = bpf_arena_map_kern_vm_start(sch->arena_map);
> #endif
> cmd->arena_map = NULL;
> +
> + /*
> + * Publishing makes @sch visible to scx_prog_sched() readers. Failure
> + * paths after this point must free @sch through kobject_put() whose
> + * release path defers the actual freeing by an RCU grace period.
> + */
> + rcu_assign_pointer(ops->priv, sch);
> +
> return sch;
>
> #ifdef CONFIG_EXT_SUB_SCHED
> --
> 2.43.0
>
prev parent reply other threads:[~2026-10-15 16:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 8:14 [PATCH v1] sched_ext: finish scheduler init before publishing ops priv Binbin Deng
2026-10-15 16:54 ` Andrea Righi [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=atEFSsTO9eT_O9ql@gpd4 \
--to=arighi@nvidia.com \
--cc=18983559317@163.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sched-ext@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.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.