Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes)

[Davide Libenzi <davidel@xmailserver.org>]

On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:

> On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
> > 
> > "At the time of generation, a determination shall be made whether the
> > signal has been generated for the process or for a specific thread
> > within the process. Signals which are generated by some action
> > attributable to a particular thread, such as a hardware fault, shall
> > be generated for the thread that caused the signal to be generated.
> 
> 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'm actually thinking we shoud -also- only handle shared signals in
> dequeue_signal() when called from a different task.

Why do you want to impose this? signalfd is a "sniffer", and the user 
controls what it can dequeue/sniff or what not. I don't see a reason of 
imposing such limits, unless there're clear technical issues.



> > dequeue_signal(tsk, ...) looks for signals first in tsk->pending and
> > then in tsk->signal->shared_pending.
> > 
> > sys_signalfd() stores current in signalfd_ctx. signalfd_read() passes
> > that context to signalfd_dequeue, which passes that that saved
> > task_struct pointer to dequeue_signal.
> > 
> > This means that a signalfd will deliver signals targeted towards
> > either the original thread that created that signalfd, or signals
> > targeted towards the process as a whole.
> >
> > This means that a single signalfd is not adequate to handle signal
> > delivery for all threads in a process, because signals targeted
> > towards threads other than the thread that originally created the
> > signalfd will never be queued to that signalfd.
> 
> Well.. you certainly need to instanciate a signalfd for every thread in
> the process if you want to get shared signals for sure.

Why? Or better, what do you mean for "instanciate"?



- Davide


-
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/