sched: core: Don't use current task_cpu when migrating with stop_one_cpu
To migrate a running task using stop_one_cpu, one has to give up
the the pi_lock and rq_lock. To safeguard against migration
between giving up those locks and actually invoking stop_one_cpu,
one has to save away task_cpu(p) before releasing pi_lock, and
use the saved value when passing it as the src_cpu argument to
stop_one_cpu. If the current task_cpu is passed in, the task may
have already been migrated to that CPU for whatever other reason.
sched_exec attempts to invoke stop_one_cpu with source CPU
set to task_cpu(task) after dropping the pi_lock. While this
doesn't result in a functional error, it is rather useless to
have the entire migration code run when the task is already
running on the destination CPU.
Change-Id: I02963ed02c7119a3d707580a191fbc86b94cdfaf
Signed-off-by:
Vikram Mulukutla <markivx@codeaurora.org>
Loading
Please register or sign in to comment