linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: vic <zandy@cs.wisc.edu>
To: Mike Coleman <mkc@mathdogs.com>,
	marcelo@conectiva.com.br, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com, alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCH] ptrace on stopped processes (2.4)
Date: Thu, 17 Jan 2002 10:57:08 -0600	[thread overview]
Message-ID: <m3advcq5jv.fsf@localhost.localdomain> (raw)
In-Reply-To: <m3adwc9woz.fsf@localhost.localdomain> <87g0632lzw.fsf@mathdogs.com>

This is to respond to feedback for the ptrace patch I sent toward the
end of december.  The original message is below.

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > +			if (signr == SIGSTOP && current->ptrace & PT_PTRACED)
> This does not I suspect do what you think - surely you want brackets ?

I agree the second term should be wrapped in parens (it is now in the
patch below); but isn't that logically equivalent to what I had?

From: Mike Coleman <mkc@mathdogs.com>:
> Also, is this something that used to work?  Or would this be a change in the
> semantics of ptrace?

This is a change of semantics at least going back to 2.2.

>> Another bug is that it is not possible to use PTRACE_DETACH to leave a
>> process stopped, because ptrace ignores SIGSTOPs sent by the tracing
>> process.
>
> Unless I'm missing something (frequently the case), there are two cases here:
> (1) the tracer wants to leave the tracee stopped, and (2) the tracer wants the
> process to continue running in as natural a way as possible, meaning without
> sending it a SIGCONT (which can cause the SIGCONT signal handler to execute).
> As things currently stand, we have behavior (2), and (1) is not possible.
> With your change, we'd have behavior (1), and (2) would not be possible.

I agree that the ability to do (2) should be preserved, but I don't
see how this patch breaks it; do you have an example?

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
>> --- linux-2.4.16/kernel/ptrace.c	Wed Nov 21 16:43:01 2001
>> +++ linux-2.4.16.1/kernel/ptrace.c	Fri Dec 21 10:42:44 2001
>> @@ -89,8 +89,10 @@
>>  		SET_LINKS(task);
>>  	}
>>  	write_unlock_irq(&tasklist_lock);
>> -
>> -	send_sig(SIGSTOP, task, 1);
>> +	if (task->state != TASK_STOPPED)
>> +		send_sig(SIGSTOP, task, 1);
>> +	else
>> +		task->exit_code = SIGSTOP;
>>  	return 0;
>>  
>>  bad:
>
> It seems that trace is started in the place different from
> usual. Then, I think PTRACE_KILL doesn't work.

I don't agree, it seems to work for me.

I'd still want to check uml and subterfuge, which I'll do after these
points are cleared up.

Thanks,
Vic

From: vic <zandy@cs.wisc.edu>
Subject: [PATCH] ptrace on stopped processes (2.4)
To: marcelo@conectiva.com.br
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com,
 alan@lxorguk.ukuu.org.uk
Date: Fri, 21 Dec 2001 13:53:32 -0600

This patch fixes a couple problems with ptrace's interaction with
stopped processes on Linux 2.4.

The most significant bug is that gdb cannot attach to a stopped
process.  Specifically, the wait that follows the PTRACE_ATTACH will
block indefinitely.

Another bug is that it is not possible to use PTRACE_DETACH to leave a
process stopped, because ptrace ignores SIGSTOPs sent by the tracing
process.

This patch is against 2.4.16 on x86.  I have tested gdb and strace.
After this patch is reviewed, I would be happy to submit an analogous
patch for the other platforms, although I cannot test it.

Vic Zandy

--- linux-2.4.16/arch/i386/kernel/signal.c      Fri Sep 14 16:15:40 2001
+++ linux-2.4.16.1/arch/i386/kernel/signal.c    Wed Jan 16 22:19:16 2002
@@ -620,9 +620,9 @@
                                continue;
                        current->exit_code = 0;
 
-                       /* The debugger continued.  Ignore SIGSTOP.  */
-                       if (signr == SIGSTOP)
-                               continue;
+                       /* The debugger continued. */
+                       if (signr == SIGSTOP && (current->ptrace & PT_PTRACED))
+                               continue; /* ignore SIGSTOP */
 
                        /* Update the siginfo structure.  Is this good?  */
                        if (signr != info.si_signo) {
--- linux-2.4.16/kernel/ptrace.c        Wed Nov 21 16:43:01 2001
+++ linux-2.4.16.1/kernel/ptrace.c      Fri Dec 21 10:42:44 2001
@@ -89,8 +89,10 @@
                SET_LINKS(task);
        }
        write_unlock_irq(&tasklist_lock);
-
-       send_sig(SIGSTOP, task, 1);
+       if (task->state != TASK_STOPPED)
+               send_sig(SIGSTOP, task, 1);
+       else
+               task->exit_code = SIGSTOP;
        return 0;
 
 bad:

  reply	other threads:[~2002-01-17 16:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-21 19:53 [PATCH] ptrace on stopped processes (2.4) vic
2001-12-21 23:19 ` Jeff Dike
2001-12-22  3:56 ` OGAWA Hirofumi
2001-12-22 17:38 ` Mike Coleman
2002-01-17 16:57   ` vic [this message]
2002-01-17 19:23     ` OGAWA Hirofumi
2002-01-23 17:58       ` vic
2002-01-23 22:14         ` OGAWA Hirofumi
2002-01-23 22:29           ` vic
2002-01-24  1:41             ` OGAWA Hirofumi
2002-01-21  3:09     ` Mike Coleman
2002-01-28 20:15       ` vic
2002-03-19  3:59         ` vic
2003-03-17 21:24 Rajesh Rajamani
2003-03-24  4:09 ` Daniel Jacobowitz
2003-03-24  6:24   ` raj
2003-03-24 15:05     ` Daniel Jacobowitz
2003-03-25 13:48       ` Werner Almesberger
2003-03-25 13:58         ` Daniel Jacobowitz
2003-03-25 14:53           ` Werner Almesberger

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=m3advcq5jv.fsf@localhost.localdomain \
    --to=zandy@cs.wisc.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=mkc@mathdogs.com \
    --cc=torvalds@transmeta.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).