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: <aCSoKBu0l-vTlScT@gpd3>
Date: Wed, 14 May 2025 16:26:48 +0200
From: Andrea Righi <arighi@...dia.com>
To: Tejun Heo <tj@...nel.org>
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

On Wed, May 14, 2025 at 10:16:30AM -0400, Tejun Heo wrote:
> 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.

Makes sense, thanks for clarifying this. With a comment on top scx_root:

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

Thanks,
-Andrea