From: Oleg Nesterov <oleg@redhat.com>
To: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Cc: Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix race copy_process() vs de_thread()
Date: Mon, 24 Aug 2009 10:53:31 +0200 [thread overview]
Message-ID: <20090824085331.GB475@redhat.com> (raw)
In-Reply-To: <20090824083826.GA475@redhat.com>
On 08/24, Oleg Nesterov wrote:
>
> On 08/24, Hiroshi Shimamoto wrote:
> >
> > The point is that de_thread() waits until other thread calls wake_up_process().
> > In __exit_signal() when sig->count == 2, the thread calls wake_up_process(),
> > and then de_thread() will continue. However if another thread is during
> > copy_process(), the sig->count is incremented at copy_signal(). That makes
> > no wake_up_process().
>
> Yes. Imho signal->count must die. But I never had time to kill it.
>
> It is not needed. For example, __exit_signal() can just check
> thread_group_leader() instead of atomic_dec_and_test(sig->count).
>
> As for this bug, I'd like to think a bit more. But how about the
> patch below? With this patch
>
> - copy_process() increments signal/live only when we know
> we start the new thread
>
> - if copy_process() fails, we just check CLONE_THREAD.
> If true - do nothing, the counters were not changed.
> If false - just release ->signal, counters must be 1.
Or we can do a bit smaller patch. But in any case, copy_process()
must not use sig->count as a refcounter.
And of course, it would be nice to avoid playing ->notify_count
games in copy_process() pathes.
Oleg
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -816,7 +816,6 @@ static int copy_signal(unsigned long clo
struct signal_struct *sig;
if (clone_flags & CLONE_THREAD) {
- atomic_inc(¤t->signal->count);
atomic_inc(¤t->signal->live);
return 0;
}
@@ -881,9 +880,7 @@ static void cleanup_signal(struct task_s
{
struct signal_struct *sig = tsk->signal;
- atomic_dec(&sig->live);
-
- if (atomic_dec_and_test(&sig->count))
+ if (atomic_dec_and_test(&sig->live))
__cleanup_signal(sig);
}
@@ -1239,6 +1236,7 @@ static struct task_struct *copy_process(
}
if (clone_flags & CLONE_THREAD) {
+ atomic_inc(¤t->signal->count);
p->group_leader = current->group_leader;
list_add_tail_rcu(&p->thread_group, &p->group_leader->thread_group);
}
next prev parent reply other threads:[~2009-08-24 8:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 4:01 [PATCH] fix race copy_process() vs de_thread() Hiroshi Shimamoto
2009-08-24 5:11 ` KAMEZAWA Hiroyuki
2009-08-24 5:58 ` [PATCH v2] " Hiroshi Shimamoto
2009-08-24 6:14 ` [PATCH] " Roland McGrath
2009-08-24 6:20 ` Roland McGrath
2009-08-24 6:32 ` Hiroshi Shimamoto
2009-08-24 8:38 ` Oleg Nesterov
2009-08-24 8:53 ` Oleg Nesterov [this message]
2009-08-24 9:15 ` Roland McGrath
2009-08-24 10:50 ` Oleg Nesterov
2009-08-24 16:27 ` [PATCH v3] " Oleg Nesterov
2009-08-24 16:57 ` Roland McGrath
2009-08-25 0:10 ` Hiroshi Shimamoto
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=20090824085331.GB475@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=h-shimamoto@ct.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.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.