Re: [PATCH v2 2/3] sched_ext: Provide scx_bpf_remote_curr()

[Andrea Righi <arighi@nvidia.com>]

On Mon, Aug 04, 2025 at 02:27:14PM +0100, Christian Loehle wrote:
> On 8/4/25 13:51, Andrea Righi wrote:
> > On Mon, Aug 04, 2025 at 12:27:42PM +0100, Christian Loehle wrote:
> >> Provide scx_bpf_remote_curr() as a way for scx schedulers to
> >> check the curr task of a remote rq, without assuming its lock
> >> is held.
> >>
> >> Many scx schedulers make use of scx_bpf_cpu_rq() to check a
> >> remote curr (e.g. to see if it should be preempted). This is
> >> problematic because scx_bpf_cpu_rq() provides access to all
> >> fields of struct rq, most of which aren't safe to use without
> >> holding the associated rq lock.
> >>
> >> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> >> ---
> >>  kernel/sched/ext.c                       | 24 ++++++++++++++++++++++++
> >>  tools/sched_ext/include/scx/common.bpf.h |  1 +
> >>  2 files changed, 25 insertions(+)
> >>
> >> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> >> index 3ea3f0f18030..1d9d9cbed0aa 100644
> >> --- a/kernel/sched/ext.c
> >> +++ b/kernel/sched/ext.c
> >> @@ -7426,6 +7426,29 @@ __bpf_kfunc struct rq *scx_bpf_cpu_rq(s32 cpu)
> >>  	return cpu_rq(cpu);
> >>  }
> >>
> >> +struct task_struct *bpf_task_acquire(struct task_struct *p);
> > 
> > Can we move include <linux/btf.h> all the way to the top? In this way we
> > don't have to add this forward declaration.
> > 
> 
> At least currently <linux/btf.h> doesn't declare bpf_task_acquire.
> I'm not quite sure what's most elegant here, none of the bpf helper
> kfuncs seem to be used from kernel code / kernel/sched/ext.c

Oh I see, it's a kfunc, so its prototype is only available in BPF.

Maybe we can use `if (refcount_inc_not_zero(&p->rcu_users))` directly,
instead of bpf_task_acquire()?

> 
> 
> >> +
> >> +/**
> >> + * scx_bpf_remote_curr - Fetch the curr of a rq without acquiring its rq lock
> >> + * @cpu: CPU of the rq
> >> + *
> >> + * Increments the refcount of the task_struct which needs to be released later.
> > 
> > Maybe we should mention that the task must be released by calling
> > bpf_task_release().
> 
> Sure.
> 
> > 
> > While at it, what do you think about renaming this to something like
> > scx_bpf_task_acquire_on_cpu(), so that it looks similar to
> > bpf_task_acquire()?
> 
> Will change it to
> bpf_task_acquire_remote_curr()?
> ..on_cpu() seems like a bit of a jump semantically.

Ack.

-Andrea