linux-kernel - Re: [RFC][PATCH] sched/ext: Split curr|donor references properly

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] [day] [month] [year] [list]

Message-ID: <aTVFBwzJGO0hr_c2@gpd4>
Date: Sun, 7 Dec 2025 10:12:39 +0100
From: Andrea Righi <arighi@...dia.com>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: John Stultz <jstultz@...gle.com>, LKML <linux-kernel@...r.kernel.org>,
	Joel Fernandes <joelaf@...gle.com>,
	Qais Yousef <qyousef@...alina.io>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Valentin Schneider <vschneid@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>,
	Zimuzo Ezeozue <zezeozue@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
	Boqun Feng <boqun.feng@...il.com>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Metin Kaya <Metin.Kaya@....com>,
	Xuewen Yan <xuewen.yan94@...il.com>,
	K Prateek Nayak <kprateek.nayak@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Tejun Heo <tj@...nel.org>, David Vernet <void@...ifault.com>,
	Changwoo Min <changwoo@...lia.com>, sched-ext@...ts.linux.dev,
	kernel-team@...roid.com
Subject: Re: [RFC][PATCH] sched/ext: Split curr|donor references properly

On Sun, Dec 07, 2025 at 09:54:32AM +0100, Andrea Righi wrote:
> On Fri, Dec 05, 2025 at 09:47:24PM -0500, Joel Fernandes wrote:
> > On Sat, Dec 06, 2025 at 12:14:45AM +0000, John Stultz wrote:
> > > With proxy-exec, we want to do the accounting against the donor
> > > most of the time. Without proxy-exec, there should be no
> > > difference as the rq->donor and rq->curr are the same.
> > > 
> > > So rework the logic to reference the rq->donor where appropriate.
> > > 
> > > Also add donor info to scx_dump_state()
> > > 
> > > Since CONFIG_SCHED_PROXY_EXEC currently depends on
> > > !CONFIG_SCHED_CLASS_EXT, this should have no effect
> > > (other then the extra donor output in scx_dump_state),
> > > but this is one step needed to eventually remove that
> > > constraint for proxy-exec.
> > > 
> > > Just wanted to send this out for early review prior to LPC.
> > > 
> > > Feedback or thoughts would be greatly appreciated!
> > 
> > Hi John,
> > 
> > I'm wondering if this will work well for BPF tasks because my understanding
> > is that some scheduler BPF programs also monitor runtime statistics. If they are unaware of proxy execution, how will it work?
> 
> Right, some schedulers are relying on p->scx.slice to evaluate task
> runtime. It'd be nice for the BPF schedulers to be aware of the donor.
> 
> > 
> > I don't see any code in the patch that passes the donor information to the
> > BPF ops, for instance. I would really like the SCX folks to chime in before
> > we can move this patch forward. Thanks for marking it as an RFC.
> > 
> > We need to get a handle on how a scheduler BPF program will pass information
> > about the donor to the currently executing task. If we can make this happen
> > transparently, that's ideal. Otherwise, we may have to pass both the donor
> > task and the currently executing task to the BPF ops.
> 
> That's what I was thinking, callbacks like ops.running(), ops.tick() and
> ops.stopping() should probably have a struct task_struct *donor argument in
> addition to struct task_struct *p. Then the BPF scheduler can decide how to
> use the donor information (this would address also the runtime evaluation).

Or, better, have a kfunc like the following (I'm just sketching it, this is
likely broken):

__bpf_kfunc struct task_struct *scx_bpf_task_donor(const struct task_struct *p)
{
	struct task_struct *curr, *donor;
	struct rq *rq;

#ifndef CONFIG_SCHED_PROXY_EXEC
	return (struct task_struct *)p;
#endif

	rq = task_rq(p);
	curr = READ_ONCE(rq->curr);
	donor = READ_ONCE(rq->donor);

	/*
	 * If @p is currently executing, return the donor.
	 *
	 * The donor can be:
	 * - same as curr (no proxy execution active)
	 * - different from curr (proxy execution: curr is running with
	 *   donor's context)
	 */
	if (curr == p)
		return donor;

	/*
	 * If @p is not currently executing (queued, sleeping, etc.),
	 * the concept of donor doesn't apply, return @p itself.
	 */
	return (struct task_struct *)p;
}

And then let the BPF scheduler decide how to use this information (while
still updating time slice and check sched_class accordingly, as John is
proposing).

-Andrea