linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Jesse Allen <the3dfxdude@gmail.com>,
	Mike Hearn <mh@codeweavers.com>, Thomas Sailer <sailer@scs.ch>,
	Eric Pouech <pouech-eric@wanadoo.fr>,
	Daniel Jacobowitz <dan@debian.org>,
	Roland McGrath <roland@redhat.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, wine-devel <wine-devel@winehq.com>
Subject: Re: ptrace single-stepping change breaks Wine
Date: Wed, 29 Dec 2004 23:26:11 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0412292256350.22893@ppc970.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0412292106400.454@bigblue.dev.mdolabs.com>



On Wed, 29 Dec 2004, Davide Libenzi wrote:
> 
> I think same. My test simply let the function processing to let thru and 
> reach the fake signal sending point.

No, your test-case doesn't even send a signal at all, because your
test-program just uses a PTRACE_SINGLESTEP without any "send signal" - so
"exit_code" will be zero after the debuggee gets released from the
"ptrace_notify()", and the suspect code will never be executed..

The problem I think I see (and which the comment alludes to) is that if
the controlling process continues the debuggee with a signal, we'll be
doing the wrong thing: the code in do_syscall_trace() will take that
signal (in "current->exit_code") and send it as a real signal to the
debuggee, but since it is debugged, it will be caught (again) by the
controlling process, which apparently in the case of Wine gets very
confused.

So I _think_ the problem happens for the following schenario:
 - wine for some reason does a PTRACE_SINGLESTEP over a system call
 - after the single-step, wine ends up trying to get the sub-process to 
   enter a signal handler with ptrace( PTRACE_CONT, ... sig)
 - the normal ptrace path (where we trap a signal - see kernel/signal.c 
   and the "ptrace_stop()" logic) handles this correctly, but 
   do_syscall_trace() will do a "send_sig()"
 - we'll try to handle the signal when returning to the traced process
 - now "get_signal_to_deliver()" will invoce the ptrace logic AGAIN, and 
   call ptrace_stop() for this fake signal, and we'll report a new event 
   to the controlling process.

Does this make sense?

If so, we have a few options:

 - very hacky one: teach all ptrace users that sometimes the signal you
   continue with can be reflected back at you, and you should just "cont
   signr"  _again_.

   This is a really bad option, partly because it's hard to tell when it's 
   just a spurious reflected signal, partly because there are many ptrace 
   users, and to a large part just because it's clearly too hacky. But it
   might be a valid approach for a Wine person who is used to Wine, and
   wants to verify whether this is indeed the schenario that triggers the
   problem..

 - Stupid approach: mark the siginfo that we send as the fake one as being 
   reflected, and have get_signal_to_deliver() not apply the ptrace 
   stopping to that.

 - Possibly cleaner approach: make system call tracing just use a proper
   SIGTRAP in the first place, and always handle all the ptrace_stop() etc
   cruft in kernel/signal.c like it handles all other calls.

I dunno. The final one looks fairly simple and clean, something like the
following, but I'm most likely overlooking some reason why this won't
work..

(And as usual, this patch has not been tested in any shape, way or form. 
In fact, it hasn't even seen an x86 machine, since I edited it out as a 
fake on my ppc64.. Somebody with more brains than me should actually try 
to get it to work)

		Linus

----
===== arch/i386/kernel/ptrace.c 1.28 vs edited =====
--- 1.28/arch/i386/kernel/ptrace.c	2004-11-22 09:44:52 -08:00
+++ edited/arch/i386/kernel/ptrace.c	2004-12-29 23:21:58 -08:00
@@ -559,6 +559,8 @@
 __attribute__((regparm(3)))
 void do_syscall_trace(struct pt_regs *regs, int entryexit)
 {
+	struct siginfo info;
+
 	if (unlikely(current->audit_context)) {
 		if (!entryexit)
 			audit_syscall_entry(current, regs->orig_eax,
@@ -573,18 +575,18 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
+
+	memset(&info, 0, sizeof(info));
+	info.si_signo = SIGTRAP;
+
 	/* the 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
-	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) &&
-				 !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0));
+	info.si_code = SIGTRAP;
+	if ((current->ptrace & PT_TRACESYSGOOD) && !test_thread_flag(TIF_SINGLESTEP))
+		info.si_code = SIGTRAP | 0x80;
+	info.si_pid = current->tgid;
+	info.si_uid = current->uid;
 
-	/*
-	 * this isn't the same as continuing with a signal, but it will do
-	 * for normal use.  strace only continues with a signal if the
-	 * stopping signal is not SIGTRAP.  -brl
-	 */
-	if (current->exit_code) {
-		send_sig(current->exit_code, current, 1);
-		current->exit_code = 0;
-	}
+	/* Send us the fakey SIGTRAP */
+	send_sig_info(SIGTRAP, &info, current);
 }

  reply	other threads:[~2004-12-30  7:27 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.58.0411151439270.2222@ppc970.osdl.org>
2004-11-15 22:53 ` ptrace single-stepping change breaks Wine Roland McGrath
2004-11-19 19:00   ` Eric Pouech
2004-11-19 19:20     ` Linus Torvalds
2004-11-19 19:33       ` Eric Pouech
2004-11-19 19:51         ` Linus Torvalds
2004-11-19 20:41           ` Eric Pouech
2004-11-19 21:22             ` Linus Torvalds
2004-11-19 21:23             ` Daniel Jacobowitz
2004-11-19 21:53               ` Linus Torvalds
2004-11-20 21:49                 ` Jesse Allen
2004-11-21  4:55                   ` Jesse Allen
2004-11-21 21:32                   ` Davide Libenzi
2004-11-21 22:33                     ` Linus Torvalds
2004-11-21 23:14                       ` Davide Libenzi
2004-11-22  1:12                         ` Linus Torvalds
2004-11-22  0:13                       ` Andreas Schwab
2004-11-22  1:07                         ` Linus Torvalds
2004-11-22  4:06                           ` Davide Libenzi
2004-11-22  4:29                             ` Linus Torvalds
2004-11-22  6:23                               ` Linus Torvalds
2004-11-22 11:06                                 ` Andreas Schwab
2004-11-22 16:27                                   ` Linus Torvalds
2004-11-22 13:46                                 ` Davide Libenzi
2004-11-22 23:15                                 ` Jesse Allen
2004-11-22 23:48                                   ` Jesse Allen
2004-11-28 17:01                                   ` Eric Pouech
2004-11-22 20:52                   ` Eric Pouech
2004-11-22 21:10                     ` Linus Torvalds
2004-11-22 22:19                       ` Mike Hearn
2004-11-22 22:25                         ` Linus Torvalds
2004-12-29  2:14                         ` Thomas Sailer
2004-12-29 15:02                           ` Mike Hearn
2004-12-29 18:53                             ` Linus Torvalds
2004-12-29 19:40                               ` Jesse Allen
2004-12-29 20:04                                 ` Linus Torvalds
2004-12-29 21:43                                   ` Jesse Allen
2004-12-30  0:44                                     ` Linus Torvalds
2004-12-30  1:13                                       ` Davide Libenzi
2004-12-30  1:55                                         ` Linus Torvalds
2004-12-30  4:51                                           ` Linus Torvalds
2004-12-30  4:58                                             ` Linus Torvalds
2004-12-30  5:07                                               ` Davide Libenzi
2004-12-30  7:26                                                 ` Linus Torvalds [this message]
2004-12-30 17:59                                                   ` Davide Libenzi
2004-12-30 18:16                                                     ` Linus Torvalds
2004-12-30 19:27                                                     ` Jesse Allen
2004-12-30 19:34                                                       ` Linus Torvalds
2004-12-30 22:46                                                         ` Linus Torvalds
2004-12-30 23:00                                                           ` Daniel Jacobowitz
2004-12-30 23:17                                                             ` Linus Torvalds
2004-12-31  5:36                                                               ` Daniel Jacobowitz
2004-12-31  5:47                                                                 ` Linus Torvalds
2004-12-31  7:00                                                                   ` Jesse Allen
2004-12-31 15:10                                                                   ` Daniel Jacobowitz
2004-12-31 17:19                                                                     ` Linus Torvalds
2005-01-01 23:20                                                                       ` Daniel Jacobowitz
2005-01-29  9:25                                                                   ` Kari Hurtta
2004-12-30 23:15                                                           ` Andi Kleen
2004-12-31  0:38                                                             ` Linus Torvalds
2004-12-31 12:35                                                               ` Andi Kleen
2004-12-31 15:16                                                                 ` Davide Libenzi
2004-12-31 17:30                                                                   ` Linus Torvalds
2004-12-31 19:55                                                                     ` Jesse Allen
2004-12-31 17:14                                                                 ` Linus Torvalds
2004-12-31  4:55                                                           ` Jesse Allen
2004-12-31  5:05                                                             ` Linus Torvalds
2004-12-31  5:38                                                               ` Daniel Jacobowitz
2004-12-30 19:19                                                   ` Davide Libenzi
2004-12-30  5:06                                           ` Davide Libenzi
2004-12-30  4:28                                       ` Jesse Allen
2004-12-29 20:56                                 ` Jesse Allen
2004-12-29 19:35                             ` Thomas Sailer
2004-12-29 20:13                               ` Jesse Allen
2004-12-30  1:49                                 ` Thomas Sailer
2004-12-30  2:10                                   ` Linus Torvalds
2004-12-30  2:39                                     ` Thomas Sailer
2004-12-30  2:57                                     ` Thomas Sailer
2004-12-30  3:15                                     ` Thomas Sailer
2004-12-30  4:15                                       ` Andrew Morton
2004-12-30 10:09                                         ` Thomas Sailer
2004-12-30 13:06                                           ` Mike Hearn
2004-12-31 13:13                                             ` Thomas Sailer
2004-12-31 13:31                                               ` Mike Hearn
2004-12-31 15:42                                                 ` Jesse Allen
2004-12-31 15:56                                                   ` Davide Libenzi
2004-12-31 15:59                                                     ` Jesse Allen
2004-12-31 22:01                                                     ` Linus Torvalds
2005-01-01 22:04                                                       ` Davide Libenzi
2005-01-01 22:14                                                         ` Linus Torvalds
2005-01-02  3:46                                                           ` Davide Libenzi
2005-01-07  4:51                                                       ` minor nit with decoding popf instruction - was " John Kacur
2005-01-07  6:48                                                         ` Linus Torvalds
2005-01-08  5:05                                                           ` John Kacur
2004-12-31 15:51                                                 ` Thomas Sailer
     [not found]                                                   ` <1104873315.3557.87.camel@littlegreen>
2005-01-04 21:21                                                     ` Andrew Morton
2005-01-05 10:43                                                     ` Thomas Sailer
2005-01-05 11:24                                                       ` Ingo Molnar
2005-01-05 11:40                                                     ` Alexandre Julliard
2004-12-30 12:11                                     ` Mike Hearn
2004-11-20  3:40               ` Roland McGrath
2004-11-19 20:59       ` Grzegorz Kulewski

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=Pine.LNX.4.58.0412292256350.22893@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=akpm@osdl.org \
    --cc=dan@debian.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mh@codeweavers.com \
    --cc=pouech-eric@wanadoo.fr \
    --cc=roland@redhat.com \
    --cc=sailer@scs.ch \
    --cc=the3dfxdude@gmail.com \
    --cc=wine-devel@winehq.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;
as well as URLs for NNTP newsgroup(s).