lkml.org 
[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Ability to manipulate fork() return values
From
Date
I need this too, for SUBTERFUGUE, as well as the other patchlet that you
(Pavel) just posted (waiting for clone and non-clone children simultaneously).

There are also three other patchlets that I believe are necessary if you want
to do really solid tracing (including clone). The particulars are available
at http://subterfugue.org/patches.html , but here is a brief rundown:

- Change do_fork so that clone children created with CLONE_PARENT are
reparented correctly. This is just the logical thing--the current behavior
is completely useless, as far as I can see. (There is a possible small
security issue, which could be addressed if needed.)

- Set the high (0x80) bit of exit_code on PTRACE_SYSCALL stops. As far as I
can tell, without this (or a variation), it's practically impossible to tell
whether a stop in this case happened due to a syscall exit or a true
SIGTRAP. (This change breaks existing versions of 'strace', but the fix is
trivial.)

- Add a new command PTRACE_GETPPID which returns the original parent pid of a
process. To see why this is needed, imagine that you're tracing a process
as it goes through a fork. Suppose the child reports (at your wait4) first,
as it is leaving the fork call. You know the child's pid, but there's no
way to find out its original ppid. If you're following a set of processes,
there may be many outstanding fork calls at any point, and when children
start reporting, you want to be able to line them up with their parents.

An alternative (and better IMO) solution would be to have the *original*
ppid reported everywhere (e.g., /proc/n/{stat,status}). The current
behavior of making ptrace reparenting visible everywhere is arguably the
wrong thing, as it confuses any processes that are watching.

I'd really like to have these in for 2.4, or hear objections so that I can try
to address them. Any advice at all on how to proceed would be welcome.

--Mike



Pavel Machek <pavel@suse.cz> writes:
> Fork behaves other than normal syscalls -- debugger is not called at
> syscall exit. This patch fixes that. It does touch only return path
> from fork(), which is "cold enough". Ability to change registers after
> fork() is essential if strace wants to work correctly with clone().
>
> [patch is against 42, but I checked it applies to 46]
> Pavel
>
> --- linux-2.3.42/arch/i386/kernel/entry.S.orig Sat Feb 5 02:07:42 2000
> +++ linux-2.3.42/arch/i386/kernel/entry.S Sat Feb 5 02:09:32 2000
> @@ -180,6 +180,8 @@
> call SYMBOL_NAME(schedule_tail)
> addl $4, %esp
> GET_CURRENT(%ebx)
> + testb $0x20,flags(%ebx) # PF_TRACESYS
> + jne tracesys_exit
> jmp ret_from_sys_call
>
> /*

--
Any sufficiently adverse technology is indistinguishable from Microsoft.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site