[lkml]   [2012]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.
    On Thu, Feb 23, 2012 at 4:33 PM, Markus Gutschke <> wrote:
    > On Thu, Feb 23, 2012 at 14:15, Indan Zupancic <> wrote:
    >> What about making SECCOMP_RET_TRAP dump core/send SIGSYS if there is
    >> no tracer with PTRACE_O_SECCOMP set?
    > Please don't make things dependent on having a tracer. There are
    > applications that don't really need a tracer; in fact, these are
    > typically the exact same applications that can benefit from receiving
    > SIGSYS and then handling it internally.
    > If a tracer was required to set this up, it would make it difficult to
    > use gdb, strace, or any other common debugging tools.
    >> Sending SIGSYS is useful, but it's quite a bit less useful if user
    >> space can't handle it in a signal handler, so I don't think it's
    >> worth it to make a unblockable version.
    > Maybe, I am not parsing your e-mail correctly. But don't we already
    > get the desired behavior, if SIGSYS is treated the same as any other
    > synchronous signal? If it is unblocked and has a handler, the
    > application can decide to handle it. If neither one of these
    > conditions is true, it terminates the program. Ulimits and
    > PR_SET_DUMPABLE determine whether a core file is generated.

    Yeah - the current patchset does that just fine. The tweak I was
    proposing was making ti possible to deliver an SIGSYS that always uses
    SIG_DFL so that you don't have to play with signal call enforcement in
    the filters.

    This is a pretty minor tweak either way.

     \ /
      Last update: 2012-02-23 23:39    [W:0.020 / U:2.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site