Hi.
[Daniel]
>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.
[Michael]
>>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?
[Daniel]
>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.
I've been playing around with ptrace a little bit myself, and have some
changes that might be what you're looking for. I don't think they affect
the fast path.
Specifically, the changes I have allow you to
- specify that you are only interested in certain system calls
- specify that you only want to be trapped if the system call fails
- specify that you only want to be trapped at entry, or failure, or
exit
(or any combination you specify)
they also provide a crude implementation of block copies, and some other
miscellaneous stuff.
If you'd like, I can send you a diff against 2.0.36 (it shouldn't be too
much work to bring it to 2.2.x if that's what you're working with).
-
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/