Messages in this thread | | | Date | Thu, 29 Mar 2018 14:02:33 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12) |
| |
----- On Mar 29, 2018, at 12:24 PM, rostedt rostedt@goodmis.org wrote:
> On Thu, 29 Mar 2018 11:39:00 -0400 (EDT) > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> 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
| |