Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934012AbXFFDaI (ORCPT ); Tue, 5 Jun 2007 23:30:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755666AbXFFD3e (ORCPT ); Tue, 5 Jun 2007 23:29:34 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:2173 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752051AbXFFD3c (ORCPT ); Tue, 5 Jun 2007 23:29:32 -0400 X-AuthUser: davidel@xmailserver.org Date: Tue, 5 Jun 2007 20:29:31 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Benjamin Herrenschmidt cc: Nicholas Miell , Linus Torvalds , Linux Kernel list , Andrew Morton , Paul Mackerras Subject: Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes) In-Reply-To: <1181098204.31677.158.camel@localhost.localdomain> Message-ID: References: <1181006711.31677.97.camel@localhost.localdomain> <1181009413.31677.117.camel@localhost.localdomain> <1181013756.31677.123.camel@localhost.localdomain> <1181023787.2785.14.camel@entropy> <1181028453.31677.127.camel@localhost.localdomain> <1181087462.2788.8.camel@entropy> <1181088936.2788.10.camel@entropy> <1181091523.2788.28.camel@entropy> <1181098204.31677.158.camel@localhost.localdomain> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2385 Lines: 60 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/