All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Paul Menage <menage@google.com>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	bblum@google.com, ebiederm@xmission.com, lizf@cn.fujitsu.com,
	matthltc@us.ibm.com, containers@lists.linux-foundation.org
Subject: Re: [RFC] [PATCH 1/2] cgroups: read-write lock CLONE_THREAD forking per threadgroup
Date: Tue, 5 Jan 2010 19:53:30 +0100	[thread overview]
Message-ID: <20100105185330.GA17545@redhat.com> (raw)
In-Reply-To: <20100103190752.GB13423@andrew.cmu.edu>

On 01/03, Ben Blum wrote:
>
> Adds functionality to read/write lock CLONE_THREAD fork()ing per-threadgroup

I didn't actually read this series, but at first glance it still has
problems...

> +struct sighand_struct *threadgroup_fork_lock(struct task_struct *tsk)

static?

> +{
> +	struct sighand_struct *sighand;
> +	struct task_struct *p;
> +
> +	/* tasklist lock protects sighand_struct's disappearance in exit(). */
> +	read_lock(&tasklist_lock);
> +
> +	/* make sure the threadgroup's state is sane before we proceed */
> +	if (unlikely(!thread_group_leader(tsk))) {
> +		/* a race with de_thread() stripped us of our leadership */
> +		read_unlock(&tasklist_lock);
> +		return ERR_PTR(-EAGAIN);

I don't understand how this can close the race with de_thread().

Suppose this tsk is the new leader, after de_thread() changed ->group_leader
and dropped tasklist_lock.

threadgroup_fork_lock() bumps sighand->count

de_thread() continues, notices oldsighand->count != 1 and switches
to the new ->sighand.

After that tsk can spawn other threads, but cgroup_fork() will use
newsighand->threadgroup_fork_lock while cgroup_attach_proc() relies
on oldsighand->threadgroup_fork_lock.

> +	/* now try to find a sighand */
> +	if (likely(tsk->sighand)) {
> +		sighand = tsk->sighand;
> +	} else {
> +		sighand = ERR_PTR(-ESRCH);
> +		/*
> +		 * tsk is exiting; try to find another thread in the group
> +		 * whose sighand pointer is still alive.
> +		 */
> +		list_for_each_entry_rcu(p, &tsk->thread_group, thread_group) {
> +			if (p->sighand) {
> +				sighand = tsk->sighand;

can't understand this "else {}" code... We hold tasklist, if the group
leader is dead (->sighand == NULL), then the whole thread group is
dead.

Even if we had another thread with ->sighand != NULL, what is the point
of "if (unlikely(!thread_group_leader(tsk)))" check then?

Oleg.


  parent reply	other threads:[~2010-01-05 18:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-20 21:14 + cgroups-add-functionality-to-read-write-lock-clone_thread-forking-per-threadgroup.patch added to -mm tree akpm
2009-08-21 10:26 ` + cgroups-add-functionality-to-read-write-lock-clone_thread-forking-pe r-threadgroup.patch " Oleg Nesterov
2009-08-21 10:45   ` Oleg Nesterov
2009-08-21 23:37     ` Paul Menage
2009-08-22 13:09       ` Oleg Nesterov
2009-08-22 13:28         ` Paul Menage
     [not found]         ` <20090822130952.GA4240-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-03 19:06           ` Ben Blum
2010-01-03 19:06             ` Ben Blum
     [not found]             ` <20100103190613.GA13423-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org>
2010-01-03 19:07               ` [RFC] [PATCH 1/2] cgroups: read-write lock CLONE_THREAD forking per threadgroup Ben Blum
2010-01-03 19:07                 ` Ben Blum
     [not found]                 ` <20100103190752.GB13423-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org>
2010-01-05 18:53                   ` Oleg Nesterov
2010-01-05 18:53                 ` Oleg Nesterov [this message]
     [not found]                   ` <20100105185330.GA17545-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-17 20:48                     ` Ben Blum
2010-01-17 20:48                       ` Ben Blum
     [not found]                       ` <20100117204833.GA29596-DC+BO+AtSRVCM1neWV3AGuCmf2DRS9x2@public.gmane.org>
2010-03-22 10:22                         ` Oleg Nesterov
2010-03-22 10:22                       ` Oleg Nesterov
     [not found]                         ` <20100322102247.GA8363-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-03-22 23:57                           ` Paul Menage
2010-03-22 23:57                         ` Paul Menage
2010-01-03 19:09               ` [RFC] [PATCH 2/2] cgroups: make procs file writable Ben Blum
2010-01-03 19:09                 ` Ben Blum
  -- strict thread matches above, loose matches on Subject: below --
2010-05-30  1:30 [RFC] [PATCH v2 0/2] cgroups: implement moving a threadgroup's threads atomically with cgroup.procs Ben Blum
     [not found] ` <20100530013002.GA762-kwnxxEB+oiWqwBT9kiuFm8WGCVk0P7UB@public.gmane.org>
2010-05-30  1:31   ` [RFC] [PATCH 1/2] cgroups: read-write lock CLONE_THREAD forking per threadgroup Ben Blum
2010-05-30  1:31     ` Ben Blum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100105185330.GA17545@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bblum@google.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.