public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luming Yu" <luming.yu@gmail.com>
To: Roland McGrath <roland@redhat.com>
Cc: Petr Tesarik <ptesarik@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race
Date: Tue, 09 Sep 2008 03:06:27 +0000	[thread overview]
Message-ID: <3877989d0809082006v496bae4i1c0736f5d55e9b9f@mail.gmail.com> (raw)
In-Reply-To: <20080627204954.34F8B154231@magilla.localdomain>

[-- Attachment #1: Type: text/plain, Size: 5131 bytes --]

Just have chance to re-check the problem. I have spotted the place that strace
misbehaves when SIGTRAP is blocked by task being straced with -f flag
(follow trace)
The problem is that after debugee blocking SIGTRAP the task's exec
path would not wake up debugger (strace) with this signal. But strace
don't know about it, and expect such a wake up. Upon receiving a
subsequent wake up,strace still thought it was a wake up from "SIGTRAP
in previous exec path". From now on, Debuger and Debugee misunderstand
each other..

With the test case posted before in this thread and a customized
kernel, I got the following debug info from kernel:

syscall_trace_enter exiting (4717)
report_exec:pid= 4717 parent=4715, real_parent=4716,current->ptrace =00000001,
report_exec:pid= 4717 parent=4715, real_parent=4716,current->ptrace =00000001,
syscall_trace_leave entering (4717, syscall:1033)
 ..sig_ignored=1..
4715, PTRACE_PEEKUSR 4717 @addr 00000830 return 00000000
4715, PTRACE_PEEKUSR 4717 @addr 000008c0 return 00000000
4715, PTRACE_PEEKUSR 4717 @addr 000008d0 return 00000000
4715, PTRACE_PEEKUSR 4717 @addr 000008d0 return 00000000
4715, PTRACE_PEEKUSR 4717 @addr 000008c0 return 00000000
syscall_trace current(4717)->exit_code(0)
syscall_trace_leave exiting (4717)
syscall_trace_enter beginning (4717, syscall: 1060)
 ..sig_ignored=1..
4715, PTRACE_PEEKUSR 4717 @addr 00000830 return 00000010
4715, PTRACE_PEEKUSR 4717 @addr 000008b8 return 00000424
syscall_trace current(4717)->exit_code(0)
syscall_trace_enter exiting (4717)

Delete the line that blocks SIGTRAP in the test case, rerun it, I got:

syscall_trace current(4724)->exit_code(0)
syscall_trace_enter exiting (4724)
report_exec:pid= 4724 parent=4722, real_parent=4723,current->ptrace =00000001,
report_exec:pid= 4724 parent=4722, real_parent=4723,current->ptrace =00000001,
syscall_trace_leave entering (4724, syscall:1033)
 ..sig_ignored=1..
4722, PTRACE_PEEKUSR 4724 @addr 00000830 return 00000000
4722, PTRACE_PEEKUSR 4724 @addr 000008c0 return 00000000
4722, PTRACE_PEEKUSR 4724 @addr 000008d0 return 00000000
4722, PTRACE_PEEKUSR 4724 @addr 000008d0 return 00000000
4722, PTRACE_PEEKUSR 4724 @addr 000008c0 return 00000000
syscall_trace current(4724)->exit_code(0)
syscall_trace_leave exiting (4724)
 ..sig_ignored=1..
4722, PTRACE_PEEKUSR 4724 @addr 00000830 return 00000000
4722, PTRACE_PEEKUSR 4724 @addr 000008b8 return 00000409
syscall_trace_enter beginning (4724, syscall: 1060)
 ..sig_ignored=1..


The attahced patch is a proposal for this problem. But I still don't know
why it is just specific to IA64.

***Note: The following patch is copy&paste, If you want apply, please
check out the attached version


Signed-off-by: Yu Luming <luming.yu@intel.com>
--------------------------------------
 include/linux/tracehook.h |    4 +++-
 kernel/signal.c           |   11 ++++++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff -Bru 0/include/linux/tracehook.h 1/include/linux/tracehook.h
--- 0/include/linux/tracehook.h 2008-08-18 20:43:21.000000000 -0400
+++ 1/include/linux/tracehook.h 2008-09-09 09:51:14.000000000 -0400
@@ -195,8 +195,10 @@
                                         struct pt_regs *regs)
 {
        if (!ptrace_event(PT_TRACE_EXEC, PTRACE_EVENT_EXEC, 0) &&
-           unlikely(task_ptrace(current) & PT_PTRACED))
+           unlikely(task_ptrace(current) & PT_PTRACED)){
                send_sig(SIGTRAP, current, 0);
+               set_tsk_thread_flag(current,TIF_SIGPENDING);
+       }
 }

 /**
diff -Bru 0/kernel/signal.c 1/kernel/signal.c
--- 0/kernel/signal.c   2008-08-18 20:43:21.000000000 -0400
+++ 1/kernel/signal.c   2008-09-09 09:50:38.000000000 -0400
@@ -384,8 +384,14 @@
 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
                        siginfo_t *info)
 {
-       int sig = next_signal(pending, mask);
+       int sig = 0;
+       int allow_trap = 0;

+       if((current->ptrace & PT_PTRACED) && sigismember(mask,SIGTRAP)){
+               sigdelset(mask,SIGTRAP);
+               allow_trap = 1;
+       }
+       sig = next_signal(pending, mask);
        if (sig) {
                if (current->notifier) {
                        if (sigismember(current->notifier_mask, sig)) {
@@ -399,6 +405,9 @@
                collect_signal(sig, pending, info);
        }

+       if(allow_trap)
+               sigaddset(mask,SIGTRAP);
+
        return sig;
}

On Fri, Jun 6, 2008 at 8:07 AM, Roland McGrath <roland@redhat.com> wrote:
>> I _guess_ this is caused by the fact that test2.sh is a shell script, so
>> the kernel executes the shell, and maybe utrace produces a second execve
>> notifications in this case? Roland, can you shed some light?
>
> Not really.  The utrace kernels Luming is trying are intended to match the
> vanilla ptrace behavior.  I don't think it's very useful to worry about the
> difference between some utrace kernel and the current vanilla kernel.
> Let's just look at what the current vanilla kernel is doing and compare
> that to what an older vanilla kernel did if older versions produced
> different results for the test case.
>
>
> Thanks,
> Roland
>

[-- Attachment #2: 44620-upstream.patch --]
[-- Type: application/octet-stream, Size: 1251 bytes --]

diff -Bru 0/include/linux/tracehook.h 1/include/linux/tracehook.h
--- 0/include/linux/tracehook.h	2008-08-18 20:43:21.000000000 -0400
+++ 1/include/linux/tracehook.h	2008-09-09 09:51:14.000000000 -0400
@@ -195,8 +195,10 @@
 					 struct pt_regs *regs)
 {
 	if (!ptrace_event(PT_TRACE_EXEC, PTRACE_EVENT_EXEC, 0) &&
-	    unlikely(task_ptrace(current) & PT_PTRACED))
+	    unlikely(task_ptrace(current) & PT_PTRACED)){
 		send_sig(SIGTRAP, current, 0);
+		set_tsk_thread_flag(current,TIF_SIGPENDING);
+	}
 }
 
 /**
diff -Bru 0/kernel/signal.c 1/kernel/signal.c
--- 0/kernel/signal.c	2008-08-18 20:43:21.000000000 -0400
+++ 1/kernel/signal.c	2008-09-09 09:50:38.000000000 -0400
@@ -384,8 +384,14 @@
 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
 			siginfo_t *info)
 {
-	int sig = next_signal(pending, mask);
+	int sig = 0;
+	int allow_trap = 0;
 
+	if((current->ptrace & PT_PTRACED) && sigismember(mask,SIGTRAP)){
+		sigdelset(mask,SIGTRAP);
+		allow_trap = 1;
+	}
+	sig = next_signal(pending, mask);
 	if (sig) {
 		if (current->notifier) {
 			if (sigismember(current->notifier_mask, sig)) {
@@ -399,6 +405,9 @@
 		collect_signal(sig, pending, info);
 	}
 
+	if(allow_trap)
+		sigaddset(mask,SIGTRAP);
+
 	return sig;
 }
 

  reply	other threads:[~2008-09-09  3:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22  2:47 [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22  8:47 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-05-22  9:16   ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22 11:18     ` Roland McGrath
2008-05-22 12:12       ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-05-22 20:39         ` Roland McGrath
2008-05-23 12:33         ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22 13:24       ` Luming Yu
2008-05-22 20:34         ` Roland McGrath
2008-05-23  3:42           ` Luming Yu
2008-05-23  4:19             ` Roland McGrath
2008-05-23  5:24               ` Luming Yu
2008-05-26  0:15                 ` Roland McGrath
2008-05-26  1:30                   ` Luming Yu
2008-05-27  3:31                     ` Luming Yu
2008-05-27  4:04                       ` Roland McGrath
2008-05-27  5:49                         ` Luming Yu
2008-05-27  6:12                           ` Roland McGrath
2008-05-27  6:25                             ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-03  6:04                               ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-06-03  9:01                                 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-03 14:32                                   ` Petr Tesarik
2008-06-03 21:01                                     ` Roland McGrath
2008-06-03 21:31                                       ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luck, Tony
2008-06-03 22:13                                         ` Roland McGrath
2008-06-10  8:23                                         ` Luming Yu
2008-06-04  2:16                                     ` Luming Yu
2008-06-04  9:16                                       ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-05  1:49                                         ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-06-05 11:16                                           ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-06  0:07                                             ` Roland McGrath
2008-09-09  3:06                                               ` Luming Yu [this message]
2008-09-10  5:55                                                 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Roland McGrath
2008-09-16  8:50                                                   ` Luming Yu
2008-09-17 17:01                                                     ` Roland McGrath
2008-09-18  5:44                                                       ` Luming Yu
2008-05-27  6:34                             ` Luming Yu
2008-05-27  8:48                             ` Luming Yu
2008-05-28  9:14                               ` Luming Yu
2008-06-03  6:02                                 ` Luming Yu
2008-05-30  8:05                               ` Roland McGrath

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=3877989d0809082006v496bae4i1c0736f5d55e9b9f@mail.gmail.com \
    --to=luming.yu@gmail.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptesarik@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox