All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Qiurong Fang <fangqiurong@kylinos.cn>
Cc: tj@kernel.org, void@manifault.com, changwoo@igalia.com,
	sched-ext@lists.linux.dev
Subject: Re: [PATCH] sched_ext: Delete sub-scheduler kobjects before releasing scx_enable_mutex
Date: Tue, 1 Sep 2026 22:17:29 +0200	[thread overview]
Message-ID: <apcy2S-8coGUYrFg@gpd4> (raw)
In-Reply-To: <20260901102240.2671888-1-fangqiurong@kylinos.cn>

Hello,

On Tue, Sep 01, 2026 at 06:22:40PM +0800, Qiurong Fang wrote:
> From: fangqiurong <fangqiurong@kylinos.cn>
> 
> The sub-scheduler disable path deletes the scheduler's kobjects after
> releasing scx_enable_mutex, while the root path deletes them before
> releasing it. A concurrent enable on the same cgroup can therefore hit
> kobject_add() with the same "sub-%llu" name still in the hierarchy and
> fail with -EEXIST, tearing down an otherwise healthy scheduler.

This race seems legit to me, but I think the commit message should clarify that
the concurrent enable must use a different struct_ops instance. Re-enabling the
same instance is rejected by the ops->priv check and a normal sequential
unregister/register is serialized.

With that:

Reviewed-by: Andrea Righi <arighi@nvidia.com>

Bonus: would it also be possible to add a sched_ext kselftest for this? The race
should be reproducible deterministically by blocking the parent's
ops.sub_detach() callback after the first child has been unlinked, and then
attaching a second struct_ops instance to the same cgroup. Without this change,
the second scheduler should exit because scx_sched_sysfs_add() returns -EEXIST;
with the change, it should attach successfully.

Thanks,
-Andrea

> 
> Move the two kobject_del() calls above mutex_unlock() to match the root
> path.
> 
> Fixes: ebeca1f930ea ("sched_ext: Introduce cgroup sub-sched support")
> Signed-off-by: fangqiurong <fangqiurong@kylinos.cn>
> ---
>  kernel/sched/ext/sub.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index a17d84db93bd..1923e3023bff 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c
> @@ -1631,6 +1631,12 @@ void scx_sub_disable(struct scx_sched *sch)
>  
>  	scx_unlink_sched(sch);
>  
> +	if (sch->sub_kset)
> +		kobject_del(&sch->sub_kset->kobj);
> +	/* not added if enable failed before scx_sched_sysfs_add() */
> +	if (sch->kobj.state_in_sysfs)
> +		kobject_del(&sch->kobj);
> +
>  	mutex_unlock(&scx_enable_mutex);
>  
>  	/*
> @@ -1661,12 +1667,6 @@ void scx_sub_disable(struct scx_sched *sch)
>  	 */
>  	WRITE_ONCE(sch->dead, true);
>  	synchronize_rcu();
> -
> -	if (sch->sub_kset)
> -		kobject_del(&sch->sub_kset->kobj);
> -	/* not added if enable failed before scx_sched_sysfs_add() */
> -	if (sch->kobj.state_in_sysfs)
> -		kobject_del(&sch->kobj);
>  }
>  
>  /* verify that a scheduler can be attached to @cgrp and return the parent */
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2026-09-01 20:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 10:22 [PATCH] sched_ext: Delete sub-scheduler kobjects before releasing scx_enable_mutex Qiurong Fang
2026-09-01 19:56 ` Tejun Heo
2026-09-02  3:22   ` Qiurong Fang
2026-09-02  6:02     ` Tejun Heo
2026-09-01 20:17 ` Andrea Righi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-09-02  6:20 Qiurong Fang

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=apcy2S-8coGUYrFg@gpd4 \
    --to=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=fangqiurong@kylinos.cn \
    --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.