linux-kernel - Re: [PATCH 1/4 sched_ext/for-6.16] sched_ext: Clean up scx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCSlvpiraPTKUqOf@mtj.duckdns.org>
Date: Wed, 14 May 2025 10:16:30 -0400
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4 sched_ext/for-6.16] sched_ext: Clean up scx_root
 usages

Hello, Andrea.

On Wed, May 14, 2025 at 11:33:05AM +0200, Andrea Righi wrote:
...
> >  static void enqueue_task_scx(struct rq *rq, struct task_struct *p, int enq_flags)
> >  {
> > +	struct scx_sched *sch = scx_root;
> 
> Do we need to use rcu_dereference(scx_root) here, as well as in all the
> occurrences above where scx_root is dereferenced?

So, if a task knows that it's attached to a scheduler instance, it knows
that the scheduler pointer can be dereferenced safely. In case of the root
scheduler, as long as any task is on SCX, naked derferences of scx_root are
safe. Also, if there are multiple scheduler instances, we wouldn't want to
use the root scheduler but rather the scheudler that's serving this task.

So, currently, the code base is in a transitional state and I'm using naked
scx_root dereferences basically as markers for necessary future
substitutions. All naked references should be safe but they aren't great in
that they'd trigger e.g. sparse warnings and generally don't look right.
I'll add a comment on top of scx_root to clarify what's going on.

Thanks.

-- 
tejun