Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934379AbXFFDiH (ORCPT ); Tue, 5 Jun 2007 23:38:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752441AbXFFDh4 (ORCPT ); Tue, 5 Jun 2007 23:37:56 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:56769 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752051AbXFFDhz (ORCPT ); Tue, 5 Jun 2007 23:37:55 -0400 Date: Tue, 5 Jun 2007 20:37:45 -0700 (PDT) From: Linus Torvalds To: Davide Libenzi cc: Benjamin Herrenschmidt , Nicholas Miell , 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: 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> 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: 1276 Lines: 29 On Tue, 5 Jun 2007, Davide Libenzi wrote: > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote: > > > > 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 agree that it would be a limitation, but it would be a sane one. How about we try to live with that limitation, if only to avoid the issue of having the private signals being stolen by anybody else. If we actually find a real-live use-case where that is bad in the future, we can re-visit the issue - it's always easier to _expand_ semantics later than it is to restrict them, so I think this thread is a good argument for starting it out in a more restricted form before people start depending on semantics that can be nasty.. Linus - 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/