Re: [scx_nest] bpf_timer_cancel() unusable from select_cpu()

On Fri, 21 Aug 2026 04:22:26 +0000, yaoyiqi (A) wrote:
> + if (!pcpu_ctx->scheduled_compaction)
> +   return 0;

stat_inc(NEST_STAT(CALLBACK_COMPACTED)) sits above this, so the stale
expiries get counted as compactions that did not happen. The counters
also stop adding up: the cancel in migrate_primary() takes
CANCELLED_COMPACTION, then the same timer still fires and takes
CALLBACK_COMPACTED, so SCHEDULED_COMPACTION no longer matches the sum
unless the core was re-armed in between. Upstream can reach the same
state, since the callback clears scheduled_compaction only at its end and
a cancel can arrive while it runs, but there it needs that race. Moving
the stat_inc() below your check would cover both.

> +    * path, which can run with local IRQs disabled or in hardirq
> +    * contexts - not merely "non-sleepable" - so the timer cancel

I would drop the "can": it looks unconditional to me. select_task_rq()
carries lockdep_assert_held(&p->pi_lock) at kernel/sched/core.c:3626, and
the paths reaching select_task_rq_scx() all hold that lock with IRQs off:

  try_to_wake_up()    scoped_guard(raw_spinlock_irqsave) 4302, call 4403
  wake_up_new_task()  raw_spin_lock_irqsave() 4957, call 4968
  sched_exec()        scoped_guard(raw_spinlock_irqsave) 5639, call 5640

So it is the caller's lock rather than the wakeup being IRQ-driven, and
sched_exec() is not a wakeup at all.

Thanks,
Zhan Xusheng