mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
synced 2026-04-18 03:23:53 -04:00
sched_ext: Clarify CPU context for running/stopping callbacks
The ops.running() and ops.stopping() callbacks can be invoked from a CPU other than the one the task is assigned to, particularly when a task property is changed, as both scx_next_task_scx() and dequeue_task_scx() may run on CPUs different from the task's target CPU. This behavior can lead to confusion or incorrect assumptions if not properly clarified, potentially resulting in bugs (see [1]). Therefore, update the documentation to clarify this aspect and advise users to use scx_bpf_task_cpu() to determine the actual CPU the task will run on or was running on. [1] https://github.com/sched-ext/scx/pull/1728 Cc: Jake Hillion <jake@hillion.co.uk> Signed-off-by: Andrea Righi <arighi@nvidia.com> Acked-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
@@ -373,6 +373,15 @@ struct sched_ext_ops {
|
||||
* @running: A task is starting to run on its associated CPU
|
||||
* @p: task starting to run
|
||||
*
|
||||
* Note that this callback may be called from a CPU other than the
|
||||
* one the task is going to run on. This can happen when a task
|
||||
* property is changed (i.e., affinity), since scx_next_task_scx(),
|
||||
* which triggers this callback, may run on a CPU different from
|
||||
* the task's assigned CPU.
|
||||
*
|
||||
* Therefore, always use scx_bpf_task_cpu(@p) to determine the
|
||||
* target CPU the task is going to use.
|
||||
*
|
||||
* See ->runnable() for explanation on the task state notifiers.
|
||||
*/
|
||||
void (*running)(struct task_struct *p);
|
||||
@@ -382,6 +391,15 @@ struct sched_ext_ops {
|
||||
* @p: task stopping to run
|
||||
* @runnable: is task @p still runnable?
|
||||
*
|
||||
* Note that this callback may be called from a CPU other than the
|
||||
* one the task was running on. This can happen when a task
|
||||
* property is changed (i.e., affinity), since dequeue_task_scx(),
|
||||
* which triggers this callback, may run on a CPU different from
|
||||
* the task's assigned CPU.
|
||||
*
|
||||
* Therefore, always use scx_bpf_task_cpu(@p) to retrieve the CPU
|
||||
* the task was running on.
|
||||
*
|
||||
* See ->runnable() for explanation on the task state notifiers. If
|
||||
* !@runnable, ->quiescent() will be invoked after this operation
|
||||
* returns.
|
||||
|
||||
Reference in New Issue
Block a user