[lkml]   [2011]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH UPDATED AGAIN 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
    On Thu, Dec 08, 2011 at 12:50:55PM -0800, Tejun Heo wrote:
    > (Note for Linus at the bottom)
    > threadgroup_lock() protected only protected against new addition to
    > the threadgroup, which was inherently somewhat incomplete and
    > problematic for its only user cgroup. On-going migration could race
    > against exec and exit leading to interesting problems - the symmetry
    > between various attach methods, task exiting during method execution,
    > ->exit() racing against attach methods, migrating task switching basic
    > properties during exec and so on.
    > This patch extends threadgroup_lock() such that it protects against
    > all three threadgroup altering operations - fork, exit and exec. For
    > exit, threadgroup_change_begin/end() calls are added to exit_signals
    > around assertion of PF_EXITING. For exec, threadgroup_[un]lock() are
    > updated to also grab and release cred_guard_mutex.
    > With this change, threadgroup_lock() guarantees that the target
    > threadgroup will remain stable - no new task will be added, no new
    > PF_EXITING will be set and exec won't happen.
    > The next patch will update cgroup so that it can take full advantage
    > of this change.
    > -v2: beefed up comment as suggested by Frederic.
    > -v3: narrowed scope of protection in exit path as suggested by
    > Frederic.
    > Signed-off-by: Tejun Heo <>
    > Reviewed-by: KAMEZAWA Hiroyuki <>
    > Acked-by: Li Zefan <>
    > Cc: Oleg Nesterov <>
    > Cc: Andrew Morton <>
    > Cc: Paul Menage <>
    > Cc: Frederic Weisbecker <>
    > Cc: Linus Torvalds <>
    > ---
    > Okay, narrowed exit path protection down to setting of PF_EXITING
    > itself. ->exit() on dangling tasks is a bit weird but I don't think
    > it's too bad. Frederic, are you okay with this version?

    Yeah that new scheme that only protects PF_EXITING may look a bit
    strange. But I think we are fine. With rcu list traversal, it should
    be safe even if a group member is concurrently dropped from the list (in that
    case all we check if its PF_EXITING then we give up). And we may
    have a concurrent ->exit() but that should be fine too.


    Acked-by: Frederic Weisbecker <>

    > Linus, if Frederic is okay with it, I'm gonna rebase the series on top
    > of freezer changes in pm tree to avoid conflicts in cgroup_freezer,
    > which sits between cgroup and freezer, both of which are going through
    > non-trivial changes, push the branch to linux-next and put pending
    > cgroup patches on top. Please scream if you're mighty unhappy with it
    > or have a better idea.
    > Thank you.

     \ /
      Last update: 2011-12-10 00:45    [W:0.022 / U:42.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site