scx: Implement scx_bpf_dispatch_cancel()

[htejun]

This can be used to implement interlocking against dequeue. e.g, Let's say there is one dsq per CPU and the scheduler can stall if a task is dispatched to a dsq which doesn't intersect with p->cpus_ptr. In the dispatch path, if you do the following:

if (bpf_cpumask_test_cpu(target_cpu, p->cpus_ptr))
	scx_bpf_dispatch(p, target_dsq, slice, 0);

The task can still end up in the wrong dsq because the cpumask can change between bpf_cpumask_test_cpu() and scx_bpf_dispatch(). However,

scx_bpf_dispatch(p, target_dsq, slice, 0);
if (!bpf_cpumask_test_cpu(target_cpu, p->cpus_ptr))
	scx_bpf_dispatch_cancel();

eliminates the race window - either the set_cpumask path sees the task dispatched or the dispatch path sees the updated cpumask. In both cases, the dispatch gets canceled as it should.

Note that in schedules which don't implement .dequeue(), depending on the implementation, there can be multiple enqueued instances of the same task. However, as long as the scheduler guarantees that there is at least one dispatch attempt on the task since the last enqueueing and that dispatch attempt interlocks against the dequeue path as above, it's guaranteed to not act upon stale information or miss dispatching an enqueued task.

Cc: Andrea Righi [email protected]

[arighi]

Looks good to me, thanks for doing this @htejun .

One question, theoretically can we have the same race if we do direct dispatch from .enqueue() or .select_cpu() targeting a CPU DSQ instead of using SCX_DSQ_LOCAL?

[htejun]

One question, theoretically can we have the same race if we do direct dispatch from .enqueue() or .select_cpu() targeting a CPU DSQ instead of using SCX_DSQ_LOCAL?

We're holding p->pi_lock across .select_cpu() and .enqueue(), so we're atomic against any attribute changes. We should be okay.