possible regression of ptrace on 2.6.26-rc1

possible regression of ptrace on 2.6.26-rc1

[wenji huang]

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

Hi,

When I tried the test case (ptrace-syscall-ret) on 2.6.26-rc1 kernel, 
found it always fails, but could pass on previous ones.

Here is the result (both in x86 and x86_64 box):

[wjhuang@10-182-121-27 single-test]$ ./ptrace-syscall-ret
./ptrace-syscall-ret: PTRACE_CONT, pid 17315, retvalue -1: No such process

In the case, a child is created and kept in syscall loop. The parent 
will trace the syscall and kill the child at last. It seems the child
is early exited, but should stay in infinite loop. Is this my 
misunderstanding or actual regression of kernel?

The test case is attached to the mail.

Thanks,
Wenji


[-- Attachment #2: ptrace-syscall-ret.c --]
[-- Type: text/x-csrc, Size: 2014 bytes --]

#include <signal.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <unistd.h>
#include <sched.h>
#include <assert.h>
#include <asm/unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <error.h>
#include <errno.h>
	      
#if defined __x86_64__ || defined __i386__
#define LOOP 10

static pid_t child;      

static void
cleanup (void)
{
  if (child != 0)
    kill (child, SIGKILL);
}

static void
handler_fail (int signo)
{
  cleanup ();

  signal (SIGABRT, SIG_DFL);
  assert (0);
}


int main(int argc, char **argv) {
     int status, j;
     long l;	      
     pid_t pid;

     setbuf (stdout, NULL);
     atexit (cleanup);
     signal (SIGABRT, handler_fail);

     child = fork();
     switch (child) 
     {
	case -1:
		assert(0);
	case 0:  
	  {  l = ptrace(PTRACE_TRACEME, 0, 0, 0);
	     assert(l==0);
	     raise(SIGSTOP);
	     while (1) { 
		l = access(".",R_OK);
		assert(l==0);
	     }	
	     assert(0); //not reached
	   } //end child
	default:
	    break;
         }
    	
 	pid = waitpid(child, &status, 0); 
	assert(pid==child);

        assert(WIFSTOPPED(status));
        assert(WSTOPSIG(status) == SIGSTOP);

	l = ptrace(PTRACE_SYSCALL,child, 0, 0);
	assert(l==0);

       	j = 0;
	while (j < LOOP){

	      pid = waitpid(child, &status, 0);
	      assert(child==pid);
		
	      assert(WIFSTOPPED(status));
	      assert(WSTOPSIG(status) == SIGTRAP);

       	      l = ptrace(PTRACE_SYSCALL, child, 0, 0);
	      assert(l==0);
	      j++;
         } //end loop

	l = ptrace(PTRACE_CONT, child, 0, SIGKILL);
	//if the following statement, always successful
	//l = ptrace(PTRACE_KILL, child, 0,0); 
	if (l < 0) {
   	    error (0, errno,"PTRACE_CONT, pid %ld, retvalue %ld",(long)child,l);
  	    return 1;
	}	
	else
	    assert(l==0);

	pid = waitpid(child, &status, 0);
	assert(child==pid);

	if (WIFEXITED(status) && WTERMSIG(status)!=SIGKILL) 
	      return 1;
	return 0;
} //end main
	      
#else
int main(int argc, char **argv) {
	return 77;
}
#endif

Re: possible regression of ptrace on 2.6.26-rc1

[Roland McGrath]

The test is racy.  I don't think the behavior that affects this has really
changed between kernel versions, you're just seeing timing effects.

When you finish the loop, you've just done a PTRACE_SYSCALL to resume
the child, but have not done a wait for it.  You then do PTRACE_CONT on
it.  If the child has stopped at its next syscall report by the time
that ptrace call checks the child, it works.  If not, it sees the child
is not yet stopped and ptrace fails with ESRCH.  

Due to hysterical raisins, PTRACE_KILL skips the "child is stopped"
check, so it will never return that error.  However, a PTRACE_KILL
request made before the child has actually stopped will not reliably do
anything (it will set child->exit_code = SIGKILL in a race with the
child itself setting current->exit_code before it stops).


Thanks,
Roland