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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux