Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934251AbXFFEgA (ORCPT ); Wed, 6 Jun 2007 00:36:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751744AbXFFEfw (ORCPT ); Wed, 6 Jun 2007 00:35:52 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:3053 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbXFFEfv (ORCPT ); Wed, 6 Jun 2007 00:35:51 -0400 X-AuthUser: davidel@xmailserver.org Date: Tue, 5 Jun 2007 21:35:50 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Linus Torvalds 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> 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: 1429 Lines: 35 On Tue, 5 Jun 2007, Linus Torvalds wrote: > 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.. Yeah, that's easy. We can exclude them at signalfd creation time. - 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/