[PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

[PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

[Changwoo Min]

Since commit 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for
trampoline.c"), the BPF prolog (__bpf_prog_enter) calls migrate_disable()
only when CONFIG_PREEMPT_RCU is enabled, via rcu_read_lock_dont_migrate().
Without CONFIG_PREEMPT_RCU, the prolog never touches migration_disabled,
so migration_disabled == 1 always means the task is truly
migration-disabled regardless of whether it is the current task.

The old unconditional p == current check was a false negative in this
case, potentially allowing a migration-disabled task to be dispatched to
a remote CPU and triggering scx_error in task_can_run_on_remote_rq().

Only apply the p == current disambiguation when CONFIG_PREEMPT_RCU is
enabled, where the ambiguity with the BPF prolog still exists.

Link: https://lore.kernel.org/lkml/20250821090609.42508-8-dongml2@chinatelecom.cn/
Signed-off-by: Changwoo Min <changwoo@igalia.com>
---
 kernel/sched/ext_idle.c | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/kernel/sched/ext_idle.c b/kernel/sched/ext_idle.c
index a61339c36902..ecf7e09b54ae 100644
--- a/kernel/sched/ext_idle.c
+++ b/kernel/sched/ext_idle.c
@@ -881,25 +881,32 @@ static bool check_builtin_idle_enabled(struct scx_sched *sch)
  * code.
  *
  * We can't simply check whether @p->migration_disabled is set in a
- * sched_ext callback, because migration is always disabled for the current
- * task while running BPF code.
+ * sched_ext callback, because the BPF prolog (__bpf_prog_enter) may disable
+ * migration for the current task while running BPF code.
  *
- * The prolog (__bpf_prog_enter) and epilog (__bpf_prog_exit) respectively
- * disable and re-enable migration. For this reason, the current task
- * inside a sched_ext callback is always a migration-disabled task.
+ * Since the BPF prolog calls migrate_disable() only when CONFIG_PREEMPT_RCU
+ * is enabled (via rcu_read_lock_dont_migrate()), migration_disabled == 1 for
+ * the current task is ambiguous only in that case: it could be from the BPF
+ * prolog rather than a real migrate_disable() call.
  *
- * Therefore, when @p->migration_disabled == 1, check whether @p is the
- * current task or not: if it is, then migration was not disabled before
- * entering the callback, otherwise migration was disabled.
+ * Without CONFIG_PREEMPT_RCU, the BPF prolog never calls migrate_disable(),
+ * so migration_disabled == 1 always means the task is truly
+ * migration-disabled.
+ *
+ * Therefore, when migration_disabled == 1 and CONFIG_PREEMPT_RCU is enabled,
+ * check whether @p is the current task or not: if it is, then migration was
+ * not disabled before entering the callback, otherwise migration was disabled.
  *
  * Returns true if @p is migration-disabled, false otherwise.
  */
 static bool is_bpf_migration_disabled(const struct task_struct *p)
 {
-	if (p->migration_disabled == 1)
-		return p != current;
-	else
-		return p->migration_disabled;
+	if (p->migration_disabled == 1) {
+		if (IS_ENABLED(CONFIG_PREEMPT_RCU))
+			return p != current;
+		return true;
+	}
+	return p->migration_disabled;
 }
 
 static s32 select_cpu_from_kfunc(struct scx_sched *sch, struct task_struct *p,
-- 
2.53.0

Re: [PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

[Andrea Righi]

On Thu, Apr 02, 2026 at 11:31:50AM +0900, Changwoo Min wrote:
> Since commit 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for
> trampoline.c"), the BPF prolog (__bpf_prog_enter) calls migrate_disable()
> only when CONFIG_PREEMPT_RCU is enabled, via rcu_read_lock_dont_migrate().
> Without CONFIG_PREEMPT_RCU, the prolog never touches migration_disabled,
> so migration_disabled == 1 always means the task is truly
> migration-disabled regardless of whether it is the current task.
> 
> The old unconditional p == current check was a false negative in this
> case, potentially allowing a migration-disabled task to be dispatched to
> a remote CPU and triggering scx_error in task_can_run_on_remote_rq().
> 
> Only apply the p == current disambiguation when CONFIG_PREEMPT_RCU is
> enabled, where the ambiguity with the BPF prolog still exists.
> 
> Link: https://lore.kernel.org/lkml/20250821090609.42508-8-dongml2@chinatelecom.cn/
> Signed-off-by: Changwoo Min <changwoo@igalia.com>

Makes sense to me. Instead of the link we should probably add:

Fixes: 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for trampoline.c")
Cc: stable@vger.kernel.org # v6.18+

So kernels with the BPF change will also pick this one.
Apart than that:

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

Thanks,
-Andrea

> ---
>  kernel/sched/ext_idle.c | 31 +++++++++++++++++++------------
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/sched/ext_idle.c b/kernel/sched/ext_idle.c
> index a61339c36902..ecf7e09b54ae 100644
> --- a/kernel/sched/ext_idle.c
> +++ b/kernel/sched/ext_idle.c
> @@ -881,25 +881,32 @@ static bool check_builtin_idle_enabled(struct scx_sched *sch)
>   * code.
>   *
>   * We can't simply check whether @p->migration_disabled is set in a
> - * sched_ext callback, because migration is always disabled for the current
> - * task while running BPF code.
> + * sched_ext callback, because the BPF prolog (__bpf_prog_enter) may disable
> + * migration for the current task while running BPF code.
>   *
> - * The prolog (__bpf_prog_enter) and epilog (__bpf_prog_exit) respectively
> - * disable and re-enable migration. For this reason, the current task
> - * inside a sched_ext callback is always a migration-disabled task.
> + * Since the BPF prolog calls migrate_disable() only when CONFIG_PREEMPT_RCU
> + * is enabled (via rcu_read_lock_dont_migrate()), migration_disabled == 1 for
> + * the current task is ambiguous only in that case: it could be from the BPF
> + * prolog rather than a real migrate_disable() call.
>   *
> - * Therefore, when @p->migration_disabled == 1, check whether @p is the
> - * current task or not: if it is, then migration was not disabled before
> - * entering the callback, otherwise migration was disabled.
> + * Without CONFIG_PREEMPT_RCU, the BPF prolog never calls migrate_disable(),
> + * so migration_disabled == 1 always means the task is truly
> + * migration-disabled.
> + *
> + * Therefore, when migration_disabled == 1 and CONFIG_PREEMPT_RCU is enabled,
> + * check whether @p is the current task or not: if it is, then migration was
> + * not disabled before entering the callback, otherwise migration was disabled.
>   *
>   * Returns true if @p is migration-disabled, false otherwise.
>   */
>  static bool is_bpf_migration_disabled(const struct task_struct *p)
>  {
> -	if (p->migration_disabled == 1)
> -		return p != current;
> -	else
> -		return p->migration_disabled;
> +	if (p->migration_disabled == 1) {
> +		if (IS_ENABLED(CONFIG_PREEMPT_RCU))
> +			return p != current;
> +		return true;
> +	}
> +	return p->migration_disabled;
>  }
>  
>  static s32 select_cpu_from_kfunc(struct scx_sched *sch, struct task_struct *p,
> -- 
> 2.53.0
> 

Re: [PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

[Kuba Piecuch]

Hi Changwoo,

On Thu Apr 2, 2026 at 2:31 AM UTC, Changwoo Min wrote:
...
>  static bool is_bpf_migration_disabled(const struct task_struct *p)
>  {
> -	if (p->migration_disabled == 1)
> -		return p != current;
> -	else
> -		return p->migration_disabled;
> +	if (p->migration_disabled == 1) {
> +		if (IS_ENABLED(CONFIG_PREEMPT_RCU))
> +			return p != current;
> +		return true;
> +	}
> +	return p->migration_disabled;
>  }

The fix looks correct, but the logic looks somewhat convoluted. How about
something like this:

 static bool is_bpf_migration_disabled(const struct task_struct *p)
 {
-       if (p->migration_disabled == 1)
-               return p != current;
-       else
-               return p->migration_disabled;
+       if (IS_ENABLED(CONFIG_PREEMPT_RCU) &&
+           p == current &&
+           !WARN_ON_ONCE(!p->migration_disabled)) {
+               return p->migration_disabled - 1;
+	}
+       return p->migration_disabled;
 }

My thinking here is: if CONFIG_PREEMPT_RCU is enabled and we're current,
subtract 1 from p->migration_disabled to account for the BPF prologue.
Otherwise just return p->migration_disabled. I've also thrown in a WARN_ON_ONCE
to help catch potential bugs if the assumption about the BPF prologue ever
changes.

Thanks,
Kuba

Re: [PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU

[Tejun Heo]

Hello,

Applied to sched_ext/for-7.0-fixes with Andrea's Reviewed-by and Fixes/Cc-stable
tags added per Andrea's suggestion.

Kuba, I'm not sure the suggested alternative is necessarily better. We can
revisit later if needed.

Thanks.

--
tejun