Date:	Thu, 07 Jun 2007 18:42:52 +0900
From:	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
To:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...sign.ru>,
	Roland McGrath <roland@...hat.com>
Cc:	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
Subject: [BUG] 2.6.22-rc4: wait4() waiting for SIGSTOP may not return if the target process is ptraced

Hi,

I found a bug on signal code. wait4() after sending SIGSTOP may not return if
the target process is ptraced. It's caused by signal redirection mechainism.
Because of the bug, sometimes strace can't detach target process correctly.

I confirmed the following kernel have this bug.

  - i386 2.6.22-rc3
  - i386 2.6.22-rc4
  - ia64 2.6.22-rc3
  - ia64 2.6.22-rc4


Assuming that there are following processes:

 - P1:     a multi thread process. It consists of thread T1 and thread T2.
 - strace: attaching P1 with -f option

When you try to kill strace by signal, strace does the following for each
thread of P1. I regard T1 as the target thread in the following process.

  1. call ptrace(PTRACE_DETACH) to detach T1. It only succeed if the T1
     already traced or stopped. If succeed, no more work is needed for the
     thread.
  2. Send SIGSTOP to the T1.
  3. call wait4() to wait for the target thread's status change.
  4. call ptrace(PTRACE_DETACH) again. It succeed because T1 is stopped.

If the target thread is TASK_RUNNING on process 1, and is TASK_TRACED on
process 2, T2 receives SIGSTOP instead of T1. Then T2 try to wake up strace
on receiving SIGSTOP, but strace is waiting for T1, so strace can't wake
up eternally. In addition, traced process can't restart after that.

I have some ideas to fix this problem. How should I do?


  1. Fix __group_complete_signal()

     Don't redirect SIGSTOP to other thread.

  2. Fix do_notify_parent_cldstop()

     use the pid of original target thread for __wake_up_parent

  3. Fix wait4()

     Wait for tgid instead of pid.

  4. Bypass the problem (or other porcesses using above rendezvous)

     Change user land program such as strace to bypass this problem.

  5. others

     Does anyone know the better solution?


I attached the recreate program as usual.

Thanks,

Satoru

-------------------------------------------------------------------------------
/*
 * recreate-ptrace-mt-wait-for-sigstop - recreate a signal bug
 *
 * ---------------------------------------------------------------------------
 * 
 * Problem
 * =======
 *
 * wait4() after sending SIGSTOP may not return if the target process is
 * ptraced.
 *
 * 
 * Assuming that there are following processes:
 *
 *   - P1:     a multi thread process. It consists of thread T1 and thread T2.
 *   - strace: attaching P1 with -f option
 *
 * When you try to kill strace by signal, strace does the following for each
 * thread of P1. I regard T1 as the target thread in the following process.
 *
 *    1. call ptrace(PTRACE_DETACH) to detach T1. It only succeed if the T1
 *       already traced or stopped. If succeed, no more work is needed for
 *       the thread.
 *    2. Send SIGSTOP to the T1.
 *    3. call wait4() to wait for the target thread's status change.
 *    4. call ptrace(PTRACE_DETACH) again. It succeed because T1 is stopped.
 *
 * If the target thread is TASK_RUNNING on process 1, and is TASK_TRACED on
 * process 2, T2 recives SIGSTOP instead of T1. Then T2 try to wake up strace
 * on receiving SIGSTOP, but strace is waiting for T1, so strace can't wake
 * up eternally. In addition, traced process can't restart after that.
 *
 * How to recreate
 * ===============
 *
 * 1. run this program
 * 
 *    $ recreate-ptrace-mt-wait-for-sigstop &
 * 
 * 2. run strace and attach this program
 *
 *    $ strace -f -p $!
 *
 * 3. C-c on your terminal
 *
 * Expected Result
 * ===============
 *
 * All threads of this program was detached safely
 * 
 * Actual Result
 * =============
 *
 * strace sleeps on wait4() eternally.
 *
 * Note
 * ====
 *
 * This program can't always recreate a problem. However recreate
 * possibility is very high.
 * 
 *----------------------------------------------------------------------
 * 
 * Copyright 2007 Satoru Takeuchi <takeuchi_satoru@...futjisu.com>
 *
 * This software may be used and distributed according to the terms
 * of the GNU General Public License, incorporated herein by reference.
 * 
 */

#include <sys/types.h>
#include <unistd.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <err.h>

void *thread_fn(void *arg)
{
	int i;

	for (;;) 
		sleep(1);
}

#define NTHREAD 64

int main(int argc, char **argv)
{
	pthread_t t[NTHREAD];
	int i;

	for (i = 0; i < NTHREAD; i++)
		if (pthread_create(&t[i], NULL, thread_fn, NULL)) {
			fprintf(stderr, "pthread_create(%d) failed\n", i);
			exit(EXIT_FAILURE);
		}

	thread_fn(NULL);

	for (i = 0; i < NTHREAD; i++)
		if (pthread_join(t[i], NULL))
			warn("pthread_join(%d) failed", i);

	exit(EXIT_SUCCESS);		    
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists