lkml.org 
[lkml]   [2008]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] cgroups: enhance task_cgroup()
    Paul Menage wrote:
    > On Fri, Nov 21, 2008 at 12:49 AM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
    >> task_cgroup() calls cgroup_subsys_state().
    >
    > No, it calls task_subsys_state()
    >
    >> and we must use rcu_read_lock() to protect cgroup_subsys_state().
    >> so we must use rcu_read_lock() to protect task_cgroup().
    >>
    >> but it'll not so friendly to caller: the callers of task_cgroup() have
    >> held cgroup_lock(). it means that struct cgroup will not be freed.
    >>
    >> So this patch add rcu_read_lock() in task_cgroup() to enhance task_cgroup().
    >> And we do NOT NEED FIX task_cgroup()'s callers, and cgroup_lock()
    >> can protect task_cgroup().
    >
    > Is there a reason to add an implicit rcu_read_lock() in task_cgroup()
    > and not directly in task_subsys_state() ?

    Yes.

    The caller have held the cgroup_lock() when it calls task_cgroup().
    After we add an implicit rcu_read_lock() in task_cgroup(),
    we don't need rcu_read_lock()/task_lock() for using task_cgroup().

    For cgroup_exit() will change tsk->cgroups, if we don't
    add an implicit rcu_read_lock() in task_cgroup(), we have to fix 7
    places which using task_cgroup().


    task_subsys_state() is different, it is used in fast path,
    If we add an implicit rcu_read_lock() in task_subsys_state(),
    we still need rcu_read_lock()/task_lock() for using it,
    so it's redundant rcu_read_lock(), and slower the fast path a little.


    Lai.

    >
    > Paul
    >




    \
     
     \ /
      Last update: 2008-11-22 03:29    [W:0.021 / U:87.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site