Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753828AbXFGJnR (ORCPT ); Thu, 7 Jun 2007 05:43:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751467AbXFGJnH (ORCPT ); Thu, 7 Jun 2007 05:43:07 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:40264 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbXFGJnF (ORCPT ); Thu, 7 Jun 2007 05:43:05 -0400 Date: Thu, 07 Jun 2007 18:42:52 +0900 Message-ID: <87vee09k2r.wl%takeuchi_satoru@jp.fujitsu.com> From: Satoru Takeuchi To: Linux Kernel , Linus Torvalds , Andrew Morton , Oleg Nesterov , Roland McGrath Cc: Satoru Takeuchi Subject: [BUG] 2.6.22-rc4: wait4() waiting for SIGSTOP may not return if the target process is ptraced User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4829 Lines: 176 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 * * This software may be used and distributed according to the terms * of the GNU General Public License, incorporated herein by reference. * */ #include #include #include #include #include #include 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/