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    [W:0.021 / U:92.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site