>
> signed-off-by: Andrew Theurer <haban...@linux.vnet.ibm.com>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index fbf1fd0..c767915 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4844,6 +4844,9 @@ bool __sched yield_to(struct task_struct *p, bool
> preempt)
>
> again:
> p_rq = task_rq(p);
> + if (task_running(p_rq, p) || p->state || !(p_rq->curr->flags &
> PF_VCPU)) {
> + goto out_no_unlock;
> + }
> double_rq_lock(rq, p_rq);
> while (task_rq(p) != p_rq) {
> double_rq_unlock(rq, p_rq);
> @@ -4856,8 +4859,6 @@ again:
> if (curr->sched_class != p->sched_class)
> goto out;
>
> - if (task_running(p_rq, p) || p->state)
> - goto out;
Is it possible that by this time the current thread takes double rq
lock, thread p could actually be running? i.e is there merit to keep
this check around even with your similar check above?
>
> yielded = curr->sched_class->yield_to_task(rq, p, preempt);
> if (yielded) {
> @@ -4879,6 +4880,7 @@ again:
>
> out:
> double_rq_unlock(rq, p_rq);
> +out_no_unlock:
> local_irq_restore(flags);
>
> if (yielded)
>
>
--
thanks and regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
