Use scx_bpf_cpu_curr() instead of deprecated scx_bpf_cpu_rq() #2734

cloehle · 2025-09-04T15:25:51Z

The new scx_bpf_cpu_curr() is queued for v6.18.
Use them instead of the soon deprecated scx_bpf_cpu_rq().

Error handling (on NULL) is kept as is for the schedulers

This needs the queued:
https://lore.kernel.org/lkml/[email protected]/

htejun

Oh, wait, you need to port the compat macro too.

arighi · 2025-09-04T16:22:18Z

scheds/rust/scx_cosmos/src/bpf/main.bpf.c

 static inline bool is_cpu_idle(s32 cpu)
 {
-	struct rq *rq = scx_bpf_cpu_rq(cpu);
+	struct task_struct *p = __COMPAT_scx_bpf_cpu_curr(cpu);


We need to add __COMPAT_scx_bpf_cpu_curr() https://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git/tree/tools/sched_ext/include/scx/compat.bpf.h?h=for-6.18#n238 to scheds/include/scx/compat.bpf.h or this won't build.

Ah I thought these were getting pulled in from the kernel source (at some point)?
Do we update both compat.bpf.h and common.h separately for kernel and scx repo?

Edit: Nevermind, I misunderstood the process, I've added the two commits (definitions and Andrea's compat helper) here now, i.e. this PR compiles and runs self-sufficient if the kernel includes the mentioned series.

arighi · 2025-09-04T16:22:58Z

scheds/rust/scx_cosmos/src/bpf/main.bpf.c

 		return false;
 	}
-	return rq->curr->flags & PF_IDLE;
+	return !!(p->flags & PF_IDLE);


nit: we probably don't need !! here, since the result would be cast to bool anyway.

multics69 · 2025-09-04T22:58:31Z

Overall LGTM.

arighi

Hm... I'm a bit confused.

We have:

BTF_ID_FLAGS(func, scx_bpf_cpu_curr, KF_RET_NULL | KF_RCU)

I thought the verifier would complain if we try to use scx_bpf_cpu_curr() outside of a bpf_rcu_read_lock/unlock() section, which is exactly what we're doing here. But the verifier is still happy and the kernel is (correctly) complaining:

[    5.938735] =============================
[    5.939878] WARNING: suspicious RCU usage
[    5.941002] sched_ext: BPF scheduler "cosmos_1.0.2_gd0e71ca_x86_64_unknown_linux_gnu_debug" enabled
[    5.943254] 6.17.0-rc1 #1-NixOS Not tainted
[    5.944477] -----------------------------
[    5.945636] kernel/sched/ext.c:6415 suspicious rcu_dereference_check() usage!

So we can fix this PR adding the proper bpf_rcu_read_lock/unlock() around __COMPAT_scx_bpf_cpu_curr(), but I'd like to understand why the verifier is happy.

@etsal do you have any idea? Thanks.

multics69

Thanks! It looks good to me.

arighi · 2025-10-28T06:42:31Z

Hi @cloehle we have all the required pieces upstream now, so I think we should definitely merge this, if you have time can you update this PR and check if everything is still up to date? Thanks!

cloehle · 2025-10-29T11:44:03Z

Andrea, the updated PR should be correct now, although for the compat layer to actually work (detect scx_bpf_cpu_curr()) we need the new
vmlinux-v6.18.h
Should I add it?

arighi · 2025-10-30T15:58:34Z

Andrea, the updated PR should be correct now, although for the compat layer to actually work (detect scx_bpf_cpu_curr()) we need the new vmlinux-v6.18.h Should I add it?

@etsal was looking at updating the vmlinux files, maybe sync with him?

etsal · 2025-10-30T16:13:20Z

Andrea, the updated PR should be correct now, although for the compat layer to actually work (detect scx_bpf_cpu_curr()) we need the new vmlinux-v6.18.h Should I add it?

@etsal was looking at updating the vmlinux files, maybe sync with him?

Yeah I'll be regenerating the vmlinux.h to include up to 6.18, will push the diff today or tomorrow.

cloehle · 2025-11-03T10:28:10Z

Any update on this @etsal ?
FWIW it can be simply hacked for testing obviously with something like:

--- a/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
+++ b/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
@@ -228459,6 +228459,7 @@ extern const struct cpumask *scx_bpf_get_online_cpumask(void) __weak __ksym;
 extern const struct cpumask *scx_bpf_get_possible_cpumask(void) __weak __ksym;
 extern void scx_bpf_kick_cpu(s32 cpu, u64 flags) __weak __ksym;
 extern u64 scx_bpf_now(void) __weak __ksym;
+extern struct task_struct *scx_bpf_cpu_curr(s32 cpu) __weak __ksym;
 extern u32 scx_bpf_nr_cpu_ids(void) __weak __ksym;
 extern u32 scx_bpf_nr_node_ids(void) __weak __ksym;
 extern s32 scx_bpf_pick_any_cpu(const struct cpumask *cpus_allowed, u64 flags) __weak __ksym;

I tested the schedulers I've touched, although some of them never seemed to call scx_bpf_cpu_rq() / __COMPAT_scx_bpf_cpu_curr() in my testing!

etsal · 2025-11-03T15:41:08Z

Any update on this @etsal ? FWIW it can be simply hacked for testing obviously with something like:

--- a/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
+++ b/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
@@ -228459,6 +228459,7 @@ extern const struct cpumask *scx_bpf_get_online_cpumask(void) __weak __ksym;
 extern const struct cpumask *scx_bpf_get_possible_cpumask(void) __weak __ksym;
 extern void scx_bpf_kick_cpu(s32 cpu, u64 flags) __weak __ksym;
 extern u64 scx_bpf_now(void) __weak __ksym;
+extern struct task_struct *scx_bpf_cpu_curr(s32 cpu) __weak __ksym;
 extern u32 scx_bpf_nr_cpu_ids(void) __weak __ksym;
 extern u32 scx_bpf_nr_node_ids(void) __weak __ksym;
 extern s32 scx_bpf_pick_any_cpu(const struct cpumask *cpus_allowed, u64 flags) __weak __ksym;

I tested the schedulers I've touched, although some of them never seemed to call scx_bpf_cpu_rq() / __COMPAT_scx_bpf_cpu_curr() in my testing!

Sorry for the delay, updating right now,

etsal · 2025-11-03T20:52:38Z

Any update on this @etsal ? FWIW it can be simply hacked for testing obviously with something like:

--- a/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
+++ b/scheds/vmlinux/arch/arm64/vmlinux-v6.16-g038d61fd6422.h
@@ -228459,6 +228459,7 @@ extern const struct cpumask *scx_bpf_get_online_cpumask(void) __weak __ksym;
 extern const struct cpumask *scx_bpf_get_possible_cpumask(void) __weak __ksym;
 extern void scx_bpf_kick_cpu(s32 cpu, u64 flags) __weak __ksym;
 extern u64 scx_bpf_now(void) __weak __ksym;
+extern struct task_struct *scx_bpf_cpu_curr(s32 cpu) __weak __ksym;
 extern u32 scx_bpf_nr_cpu_ids(void) __weak __ksym;
 extern u32 scx_bpf_nr_node_ids(void) __weak __ksym;
 extern s32 scx_bpf_pick_any_cpu(const struct cpumask *cpus_allowed, u64 flags) __weak __ksym;

I tested the schedulers I've touched, although some of them never seemed to call scx_bpf_cpu_rq() / __COMPAT_scx_bpf_cpu_curr() in my testing!

Sorry for the delay, updating right now,

Hitting an issue with our scripts not properly generating vmlinux.h for the arm target on Fedora, I will just upload the rest of the archs for now.

The new functions provide a safer way to access a rq or a remote rq->curr respectively. They are both part of v6.18. See kernel commits: e0ca169638be ("sched_ext: Introduce scx_bpf_locked_rq()") 20b158094a1a ("sched_ext: Introduce scx_bpf_cpu_curr()") Signed-off-by: Christian Loehle <[email protected]>

Introduce a compatibility helper that allows BPF schedulers to use scx_bpf_cpu_curr() on older kernels. See kernel commit 20b158094a1a ("sched_ext: Introduce scx_bpf_cpu_curr()") Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Christian Loehle <[email protected]>

cloehle · 2025-11-04T23:31:37Z

Thank you Emil!
So I've rebased the patches and retested them, should be all good.
Note that I couldn't actually reach the scx_bpf_cpu_curr compat header call in my testing of
flash, layered
So only
lavd, tickless, cosmos are really tested.

mati865 · 2025-11-05T01:10:36Z

#2734 (comment) still isn't addressed or replied.
(the comment about !!)

cloehle · 2025-11-05T08:40:53Z

@mati865 Oops, sorry about that, I'll fix it right away.

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

cloehle · 2025-11-14T09:14:11Z

Gentle ping on this!

arighi

For my stuff this looks good, I think we can merge it.

@multics69 @hodgesds what do you think about the changes to lavd and layered?

cloehle mentioned this pull request Sep 4, 2025

Use scx_bpf_remote_curr() instead of scx_bpf_cpu_rq() #2555

Closed

htejun approved these changes Sep 4, 2025

View reviewed changes

htejun reviewed Sep 4, 2025

View reviewed changes

arighi reviewed Sep 4, 2025

View reviewed changes

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch from 8d41e53 to 11bb34c Compare September 4, 2025 22:50

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch from 11bb34c to 9deff4b Compare September 4, 2025 23:32

arighi approved these changes Sep 6, 2025

View reviewed changes

arighi added this pull request to the merge queue Sep 6, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 6, 2025

arighi requested changes Sep 6, 2025

View reviewed changes

multics69 approved these changes Sep 7, 2025

View reviewed changes

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch 2 times, most recently from eb700fc to 5cd7c5f Compare September 7, 2025 21:12

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch from 5cd7c5f to 9de9b92 Compare October 29, 2025 11:40

cloehle added 2 commits November 4, 2025 09:26

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch from 9de9b92 to e3e914b Compare November 4, 2025 09:26

cloehle added 2 commits November 5, 2025 08:42

scx_cosmos: Use scx_bpf_cpu_curr()

cb1428e

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

scx_flash: Use scx_bpf_cpu_curr()

b54c546

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

cloehle added 3 commits November 5, 2025 08:42

scx_lavd: Use scx_bpf_cpu_curr()

a4b6928

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

scx_layered: Use scx_bpf_cpu_curr()

4d3158c

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

scx_tickless: Use scx_bpf_cpu_curr()

6a9363a

Use the new scx_bpf_cpu_curr() introduced in v6.18 as a safer way to access rq->curr instead of the deprecated scx_bpf_cpu_rq(). Signed-off-by: Christian Loehle <[email protected]>

cloehle force-pushed the cloehle/scx_bpf_cpu_rq-compat branch from e3e914b to 6a9363a Compare November 5, 2025 08:42

arighi approved these changes Nov 14, 2025

View reviewed changes

Use scx_bpf_cpu_curr() instead of deprecated scx_bpf_cpu_rq() #2734

Are you sure you want to change the base?

Use scx_bpf_cpu_curr() instead of deprecated scx_bpf_cpu_rq() #2734

Uh oh!

Conversation

cloehle commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

htejun left a comment

Choose a reason for hiding this comment

Uh oh!

arighi Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cloehle Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arighi Sep 4, 2025

Choose a reason for hiding this comment

Uh oh!

multics69 commented Sep 4, 2025

Uh oh!

Uh oh!

arighi left a comment

Choose a reason for hiding this comment

Uh oh!

multics69 left a comment

Choose a reason for hiding this comment

Uh oh!

arighi commented Oct 28, 2025

Uh oh!

cloehle commented Oct 29, 2025

Uh oh!

arighi commented Oct 30, 2025

Uh oh!

etsal commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cloehle commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etsal commented Nov 3, 2025

Uh oh!

etsal commented Nov 3, 2025

Uh oh!

cloehle commented Nov 4, 2025

Uh oh!

mati865 commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cloehle commented Nov 5, 2025

Uh oh!

cloehle commented Nov 14, 2025

Uh oh!

arighi left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

cloehle commented Sep 4, 2025 •

edited

Loading

arighi Sep 4, 2025 •

edited

Loading

cloehle Sep 4, 2025 •

edited

Loading

etsal commented Oct 30, 2025 •

edited

Loading

cloehle commented Nov 3, 2025 •

edited

Loading

mati865 commented Nov 5, 2025 •

edited

Loading