----- On Mar 29, 2018, at 2:07 PM, rostedt rostedt@xxxxxxxxxxx wrote: > On Thu, 29 Mar 2018 14:02:33 -0400 (EDT) > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > >> Currently, anyone using ptrace on a process has pretty much given up all >> hopes of performance. Processes will use rseq to gain performance, not the >> opposite, so this deterioration will be unwelcome. > > The ptrace path has nothing to do with ptrace anymore, and probably be > hard to notice the performance hit. You simply set a TIF flag, and on > exit of the syscall it jumps to a path that checks special cases > (tracing system calls being one of them). It's called the ptrace path > because ptrace was the first one to use it (I'm guessing, I haven't > actually looked at the history). Last time I checked, it's not only a jump, it's actually saving/restoring tons of registers. Did this change recently ? I use it for LTTng syscall tracing too. My experience so far is that it's really terribly slow. I've been waiting on Andy Lutomirski to complete his changes in that area to look into making this faster for syscall tracepoints. > > This is used to add any system call checks that are not done during > normal operation. And this certainly falls under that category. I know it's used for stuff like seccomp too. My guess has always been that security people care much more about robustness than performance. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
