lkml.org 
[lkml]   [2018]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2018-03-29 20:38    [W:5.398 / U:0.280 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site