[lkml]   [2011]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH UPDATED 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
    On Thu, Nov 24, 2011 at 2:50 PM, Tejun Heo <> wrote:
    > Linus, this is something being scheduled for the next merge window.
    > It extends threadgroup locking which cgroup used to do to exclude only
    > fork path so that it includes exit and exec paths.  threadgroup
    > locking is used by cgroup to implement process-scope cgroup migration.
    > Migration happens in multiple steps, at each of which the matching
    > method of each cgroup plugin is called.  When a whole process is being
    > migrated, methods being called at those different steps expect to see
    > consistent image of the thread group.


    I see why you want to do this, but I really don't much like some of it.

    I've got a few questions:

    - do you even *need* two separate locks at all? If you extend the
    threadgroup_fork_lock to cover exec/exit too (and rename it), then why
    does that separate cred_guard_mutex make sense at all?

    Taking two locks for the common exit case seems disgusting. What do
    the separate locks buy us?

    - could we possible avoid the lock(s) entirely for the
    single-threaded case? The fact that ptrace wants to serialize makes me
    say "maybe we can't avoid it", but I thought I'd ask. Even if we do
    need/want two separate locks, do we really want to take them both for
    the case that shouldn't really need even a single one?

    Hmm? Simplifying the locking rules is always a good idea, and I think
    this seems to make some of it more straightforward, but at the same
    time I shudder when I look at some of the patches in the series that
    nest locking three locks deep. Ugh.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-11-25 05:05    [W:0.035 / U:6.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site