Messages in this thread | | | Subject | Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes) | From | Benjamin Herrenschmidt <> | Date | Wed, 06 Jun 2007 14:18:25 +1000 |
| |
> 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.
I agree, with an appropriate fix to recalc_sigpending_tsk() to only clear TIF_SIGPENDING if tsk == current (the patch Linus posted basically) _along_ with a fix to avoid the notifier thingy if stealing from another task, that would work.
> 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.
I agree there too. I don't see the point of the 'feature' of allowing those to be stolen and can only lead into all sort of new headaches nobody needs.
> 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.)
Heh, well, as you say later, it can't be delivered anyway... I don't think we need to do anything explicit to prevent them from being read() in signalfd, it will just not happen.
> 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
Ben.
- 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/
| |