Remote consumption now reaches the !dsq branch with holding_cpu set, just like direct dispatch. Also, the dsq-present branch races with unlink_dsq_and_switch_rq_lock(), not dispatch_to_local_dsq(). Update both comments to describe the current transfer paths. No functional change. Suggested-by: Tejun Heo Signed-off-by: Usama Arif --- kernel/sched/ext/ext.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c index 0135ff6824b03..f95d1cf8d3d1c 100644 --- a/kernel/sched/ext/ext.c +++ b/kernel/sched/ext/ext.c @@ -1832,10 +1832,9 @@ void scx_dispatch_dequeue(struct rq *rq, struct task_struct *p) list_del_init(&p->scx.dsq_list.node); /* - * When dispatching directly from the BPF scheduler to a local - * DSQ, the task isn't associated with any DSQ but - * @p->scx.holding_cpu may be set under the protection of - * %SCX_OPSS_DISPATCHING. + * When moving a task to a local DSQ through either direct dispatch + * or remote consumption, the task isn't associated with any DSQ but + * @p->scx.holding_cpu may be set. */ if (p->scx.holding_cpu >= 0) p->scx.holding_cpu = -1; @@ -1855,9 +1854,9 @@ void scx_dispatch_dequeue(struct rq *rq, struct task_struct *p) scx_task_unlink_from_dsq(p, dsq); } else { /* - * We're racing against dispatch_to_local_dsq() which already - * removed @p from @dsq and set @p->scx.holding_cpu. Clear the - * holding_cpu which tells dispatch_to_local_dsq() that it lost + * We're racing against unlink_dsq_and_switch_rq_lock(), which + * already removed @p from @dsq and set @p->scx.holding_cpu. Clear + * holding_cpu to tell unlink_dsq_and_switch_rq_lock() that it lost * the race. */ WARN_ON_ONCE(!list_empty(&p->scx.dsq_list.node)); -- 2.53.0-Meta