lkml.org 
[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    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    [W:0.023 / U:59.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site