[lkml]   [2007]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes)
    On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
    > On Tue, 5 Jun 2007, Davide Libenzi wrote:
    > > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
    > > >
    > > > Yeah, synchronous signals should probably never be delivered to another
    > > > process, even via signalfd. There's no point delivering a SEGV to
    > > > somebody else :-)
    > >
    > > That'd be a limitation. Like you can choose to not handle SEGV, you can
    > > choose to have a signalfd listening to it. Of course, not with the
    > > intention to *handle* the signal, but with a notification intent.
    > I agree that it would be a limitation, but it would be a sane one.
    > How about we try to live with that limitation, if only to avoid the issue
    > of having the private signals being stolen by anybody else. If we actually
    > find a real-live use-case where that is bad in the future, we can re-visit
    > the issue - it's always easier to _expand_ semantics later than it is to
    > restrict them, so I think this thread is a good argument for starting it
    > out in a more restricted form before people start depending on semantics
    > that can be nasty..
    > Linus

    Proposed semantics:

    a) Process-global signals can be read by any thread (inside or outside
    of the process receiving the signal).

    This should always work, so there's no reason to limit it.

    b) Thread-specific signals can only be read by their target thread.

    This behavior is required by POSIX, and if an application is using
    pthread_kill()/tkill()/tgkill()/etc. to specifically direct a signal, it
    damn well better get to where the app wants it to go.

    c) Synchronous signals ("Naturally" generated SIGILL, SIGFPE, SIGSEGV,
    SIGBUS, and SIGTRAP. Did I miss any?) are not delivered via signalfd()
    at all. (And by "naturally" generated, I mean signals that would have
    the SI_KERNEL flag set.)

    These are a subset of thread-specific signals, so they can only be read
    from a signalfd by their target thread.

    However, there's no way for the target thread to get the signal because
    it is either:

    a) not blocked in a syscall waiting for signal delivery and thus further
    execution beyond the instruction causing the signal is impossible
    b) it is blocked in a syscall waiting for signal delivery and the error
    is caused by the signal delivery mechanism itself (i.e. a bad pointer
    passed to read/select/poll/epoll_wait/etc.) and thus the signal can't be

    Nicholas Miell <>

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-06 06:11    [W:0.038 / U:77.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site