On Thu, 29 Mar 2018 14:35:16 -0400 (EDT) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > ----- 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 gives us more incentive to help Andy make it faster ;-) -- Steve > > > > > 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 > > -- 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
