Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765930AbXFFCu3 (ORCPT ); Tue, 5 Jun 2007 22:50:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751182AbXFFCuV (ORCPT ); Tue, 5 Jun 2007 22:50:21 -0400 Received: from gate.crashing.org ([63.228.1.57]:45312 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbXFFCuV (ORCPT ); Tue, 5 Jun 2007 22:50:21 -0400 Subject: Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes) From: Benjamin Herrenschmidt To: Nicholas Miell Cc: Davide Libenzi , Linus Torvalds , Linux Kernel list , Andrew Morton , Paul Mackerras In-Reply-To: <1181091523.2788.28.camel@entropy> 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> Content-Type: text/plain Date: Wed, 06 Jun 2007 12:50:04 +1000 Message-Id: <1181098204.31677.158.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2029 Lines: 48 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/