All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2] fix race copy_process() vs de_thread()
Date: Mon, 24 Aug 2009 14:58:14 +0900	[thread overview]
Message-ID: <4A922BF6.4010607@ct.jp.nec.com> (raw)
In-Reply-To: <20090824141141.0893a2c0.kamezawa.hiroyu@jp.fujitsu.com>

KAMEZAWA Hiroyuki wrote:
> On Mon, 24 Aug 2009 13:01:40 +0900
> Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> wrote:
>  
>> Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>> ---
>>  kernel/fork.c |   12 ++++++++++++
>>  1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 3ffa10f..be6c5b5 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -882,6 +882,9 @@ static void cleanup_signal(struct task_struct *tsk)
>>  {
>>  	struct signal_struct *sig = tsk->signal;
>>  
>> +	if (!sig)
>> +		return;
>> +
>>  	atomic_dec(&sig->live);
>>  
>>  	if (atomic_dec_and_test(&sig->count))
>> @@ -1230,6 +1233,15 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>>   	 */
>>  	recalc_sigpending();
>>  	if (signal_pending(current)) {
>> +		/* If there is any task waiting for the group exit, notify it */
>> +		if ((clone_flags & CLONE_THREAD) &&
>> +		    p->signal->group_exit_task) {
>> +			atomic_dec(&p->signal->live);
>> +			atomic_dec(&p->signal->count);
>> +			if (atomic_read(&p->signal->count) == p->signal->notify_count)
>> +				wake_up_process(p->signal->group_exit_task);
>> +			p->signal = NULL;
>> +		}
>>  		spin_unlock(&current->sighand->siglock);
>>  		write_unlock_irq(&tasklist_lock);
>>  		retval = -ERESTARTNOINTR;
> 
> I'm not sure whehter I catch the issue correctly but, shouldn't we encapsulate
> this check in cleanup_signal() ?

Ah, you're right. clone_process() may fail several reasons and failures after
copy_signal() will cause this issue.

> 
> like...
> 
> static void cleanup_signal(struct task_struct *tsk)
> {
>         struct signal_struct *sig = tsk->signal;
> 	sighand = rcu_dereference(tsk->sighand);
>  
>         spin_lock(&sighand->siglock);
>         if (sig->group_exit_task && atomic_read(&sig->count) == sig->notify_count)
>  		wake_up_process(sig->group_exit_task);
> 	spin_unlock(&sighand->siglock);
> 
> 	atomic_dec(&sig->live);
> 	if (!atomic_dec_and_test(&sig->count))
> 		 __cleanup_signal(sig);
> }
> 
> 
> BTW, why sig->xxx members in "signal" struct is guarded by lock in "sighand"
> struct ??

I don't know.

Update version is below.

Thanks,
Hiroshi

========
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>

There is a race between de_thread() and copy_process().
When a thread is during execve and another thread is during clone, a exec-ing
thread may be hung up in de_thread() waiting other threads are finished.
The root cause is that cleanup_signal() which is called when fork() failed
doesn't cause wake up the waiting thread at de_thread(), because there is no
check signal->count.

We need the check signal->group_exit_task and signal->notify_count.

Here is a reproducer, it may generate a thread which never die.

void *null_thread(void *p)
{
	for (;;)
		sleep(1);

	return NULL;
}

void *exec_thread(void *p)
{
	execl("/bin/true", "/bin/true", NULL);

	return null_thread(p);
}

int main(int argc, char **argv)
{
	for (;;) {
		pid_t pid;
		int ret, status;

		pid = fork();
		if (pid < 0)
			break;

		if (!pid) {
			pthread_t tid;

			pthread_create(&tid, NULL, exec_thread, NULL);
			for (;;)
				pthread_create(&tid, NULL, null_thread, NULL);
		}

		do {
			ret = waitpid(pid, &status, 0);
		} while (ret == -1 && errno == EINTR);
	}

	return 0;
}

Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
---
 kernel/fork.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 3ffa10f..bc41c41 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -886,6 +886,14 @@ static void cleanup_signal(struct task_struct *tsk)
 
 	if (atomic_dec_and_test(&sig->count))
 		__cleanup_signal(sig);
+	else {
+		/* If there is any task waiting for the group exit, notify it */
+		spin_lock(&tsk->sighand->siglock);
+		if (sig->group_exit_task &&
+		    atomic_read(&sig->count) == sig->notify_count)
+			wake_up_process(sig->group_exit_task);
+		spin_unlock(&tsk->sighand->siglock);
+	}
 }
 
 static void copy_flags(unsigned long clone_flags, struct task_struct *p)
-- 
1.6.3.3


  reply	other threads:[~2009-08-24  6:00 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   ` Hiroshi Shimamoto [this message]
2009-08-24  6:14 ` 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
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=4A922BF6.4010607@ct.jp.nec.com \
    --to=h-shimamoto@ct.jp.nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --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.