lkml.org 
[lkml]   [2011]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched: RCU-protect __set_task_cpu() in set_task_cpu()
On 06/03, Peter Zijlstra wrote:
>
> @@ -2200,6 +2201,16 @@ void set_task_cpu(struct task_struct *p,
> !(task_thread_info(p)->preempt_count & PREEMPT_ACTIVE));
>
> #ifdef CONFIG_LOCKDEP
> + /*
> + * The caller should hold either p->pi_lock or rq->lock, when changing
> + * a task's CPU.

Is it literally true? IIRC, we need ->pi_lock if the task is not active,
and rq->lock if p->on_rq = 1. And that is why we do not clear p->on_rq
between deactivate_task() + activate_task(), correct?

> + *
> + * sched_move_task() holds both and thus holding either pins the cgroup,
> + * see set_task_rq().
> + *
> + * Furthermore, all task_rq users should acquire both locks, see
> + * task_rq_lock().
> + */
> WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) ||
> lockdep_is_held(&task_rq(p)->lock)));

IOW, perhaps this should be

WARN_ON_ONCE(debug_locks && !lockdep_is_held(p->on_rq ?
&task_rq(p)->lock : &p->pi_lock))

?

Not that I really suggest to change this WARN_ON(), I am just trying
to recall the new rules.

Oleg.



\
 
 \ /
  Last update: 2011-06-05 21:17    [from the cache]
©2003-2011 Jasper Spaans