Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

[Steven Rostedt]

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
> 
>