lkml.org 
[lkml]   [2007]   [Jun]   [5]   [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)
From
Date
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 :-)

I'm actually thinking we shoud -also- only handle shared signals in
dequeue_signal() when called from a different task.

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

BTW. Not directly related, but that notifier thing ... it looks really
really dodgy. It's also only ever used by the DRM. Somebody around knows
why that's in and why the DRM cannot just use normal signal blocking
techniques ?

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

\
 
 \ /
  Last update: 2007-06-06 04:53    [W:1.399 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site