Re: + cgroups-add-functionality-to-read-write-lock-clone_thread-forking-pe r-threadgroup.patch added to -mm tree

[Paul Menage <menage@google.com>]

On Sat, Aug 22, 2009 at 6:09 AM, Oleg Nesterov<oleg@redhat.com> wrote:
>
>
> And why do we need sighand->threadgroup_fork_lock ? I gueess, to protect
> against clone(CLONE_THREAD).

Right - we want to be able to atomically move all the threads in the
thread group into a new cgroup, without leaving any behind if we
happen to race with a clone(CLONE_THREAD).

Putting the lock in the sighand structure seemed like an appropriate
place since it's involved in existing clone() synchronization.

>
> threadgroup_fork_lock() bumps P->sighand->count. If P exec, it will
> notice sighand->count != 1 and switch to another ->sighand.

So maybe we should also down_read(threadgroup_fork_lock) in the exec
path? That would prevent a child thread from execing and taking over
the group leadership, so it would remain safe to iterate over the
group leader's thread list.

Paul