----- On Mar 29, 2018, at 12:24 PM, rostedt rostedt@xxxxxxxxxxx wrote: > On Thu, 29 Mar 2018 11:39:00 -0400 (EDT) > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > >> Enforcing SIGSEGV on syscall entry when nested in a rseq critical section >> will not be free both in terms of syscall overhead, and in terms of code >> maintenance: we'd need to add those checks into entry.S for each architecture >> supported, which pretty much doubles the amount of architecture-specific >> code we need to implement for rseq. Currently, all we need is to hook in >> signal delivery and wire up the system call numbers. > > Why not have the check on syscall exit? Then we could use the ptrace > type mechanism to only go that path when a rseq exists for the program. 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. One thing I would find more acceptable is to only compile in this check under a CONFIG_DEBUG_RSEQ option or something similar. This means we can then put the check at the most convenient location without caring too much about its performance impact. Thoughts ? 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
