Does it seem reasonable to change the test to check against PF_PTRACED,
and have the slow path then check for PF_TRACESYS, or any other
necessary flag(s) both before and after the system call itself? This
would only slow down ptraced programs, and then only by a small amount.
>But I think you can just do everything you want in user-space anyways.
>Why don't you just turn on PF_TRACESYS at the beginning of execution,
>and then keep your own state in your parent process about which traps
>to take action on and which to pass through?
Unfortunately, for my purposes, this is far too slow. Two traps per
system call would kill any performance my program has. I'd be happy to
find a user space solution to this which didn't require PF_TRACESYS to
be on for the entire execution of the program, though.
- Daniel Nash
http://www.cs.wisc.edu/paradyn/
Paradyn Parallel Performance Tools
University of Wisconsin - Madison
-
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/