Messages in this thread | | | Subject | Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes) | From | Nicholas Miell <> | Date | Tue, 05 Jun 2007 21:08:41 -0700 |
| |
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).
Rationale: This should always work, so there's no reason to limit it.
b) Thread-specific signals can only be read by their target thread.
Rationale: 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.)
Rationale: 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 OR 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 delivered
-- Nicholas Miell <nmiell@comcast.net>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |