Re: [PATCH v2 1/2] sched_ext: Add cookie API for early qseq capture

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scx_bpf_task_get_cookie() reads the sequence counter (ops_state) without acquire semantics, failing to prevent the BPF program's pre-dispatch checks from being reordered before the cookie capture.
--

commit 4466cb81e5097999461b1978bdcc6623cb37dcf1
Author: Cheng-Yang Chou <yphbchou0911@gmail.com>
sched_ext: Add cookie API for early qseq capture

This commit introduces a cookie API for early qseq capture, extending the
protection window for BPF-side pre-dispatch checks against concurrent
dequeue/re-enqueue races.

Link: https://lore.kernel.org/r/20260203230639.1259869-1-arighi@nvidia.com/

> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 5600618dcef8e..f28baf7ce79cc 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c

[ ... ]

> @@ -8505,13 +8507,71 @@ __bpf_kfunc void scx_bpf_dsq_insert_vtime(struct task_struct *p, u64 dsq_id,
>  	scx_dsq_insert_vtime(sch, p, dsq_id, slice, vtime, enq_flags);
>  }
>  
> +/**
> + * scx_bpf_task_get_cookie - Get an opaque dispatch cookie for a task
> + * @p: task_struct to read cookie from
> + *
> + * Returns an opaque u64 dispatch cookie. Pass the cookie to
> + * scx_bpf_dsq_insert_with_cookie() to extend the time window during
> + * which sched_ext will detect racing dequeues/enqueues of @p. The
> + * extended window begins with this call and ends at the same point as
> + * for dispatches without cookies, i.e. when sched_ext attempts to
> + * finish the dispatch.
> + *
> + * This API is intended for schedulers that do not implement properly
> + * synchronized dequeue.
> + */
> +__bpf_kfunc u64 scx_bpf_task_get_cookie(struct task_struct *p)
> +{
> +	return atomic_long_read(&p->scx.ops_state) & SCX_OPSS_QSEQ_MASK;
> +}

Does this sequence counter read require acquire semantics?

Because this kfunc acts as the read-begin phase of a sequence lock for the
BPF program, using atomic_long_read() might allow the CPU to speculatively
reorder the BPF program's subsequent memory loads before the ops_state read
on weakly-ordered architectures.

If a concurrent task state update occurs between the reordered data read and
the ops_state read, could the CPU fetch stale task data but capture the new
ops_state as its cookie?

Could this missing ordering cause a regression where the dispatch is falsely
validated later, since the cookie would match the task's current ops_state?

Would it make sense to use atomic_long_read_acquire() here or include an
smp_rmb() to enforce the necessary load-load ordering?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506160412.522199-1-yphbchou0911@gmail.com?part=1