Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758893AbXFVXwY (ORCPT ); Fri, 22 Jun 2007 19:52:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751980AbXFVXwR (ORCPT ); Fri, 22 Jun 2007 19:52:17 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]:53122 "EHLO sccrmhc13.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508AbXFVXwQ (ORCPT ); Fri, 22 Jun 2007 19:52:16 -0400 X-Greylist: delayed 301 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Jun 2007 19:52:16 EDT Subject: Re: Fix signalfd interaction with thread-private signals From: Nicholas Miell To: Benjamin Herrenschmidt Cc: Linus Torvalds , Oleg Nesterov , Davide Libenzi , Linux Kernel Mailing List In-Reply-To: <1182554371.24740.87.camel@localhost.localdomain> References: <20070620111415.GA91@tv-sign.ru> <20070621082509.GA88@tv-sign.ru> <20070621182340.GA92@tv-sign.ru> <20070621185856.GA153@tv-sign.ru> <1182468604.24740.22.camel@localhost.localdomain> <20070622084034.GA134@tv-sign.ru> <1182512473.24740.54.camel@localhost.localdomain> <20070622160405.GA189@tv-sign.ru> <1182551618.24740.79.camel@localhost.localdomain> <1182554190.24740.84.camel@localhost.localdomain> <1182554371.24740.87.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 22 Jun 2007 16:42:07 -0700 Message-Id: <1182555727.2735.3.camel@entropy> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 (2.10.2-2.fc7.0.njm.1) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1746 Lines: 40 On Sat, 2007-06-23 at 09:19 +1000, Benjamin Herrenschmidt wrote: > On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote: > > > Quite frankly, it strikes me that if we want to do this, then we shouldn't > > > save the _process_ information at all, we should save the "sighand" > > > instead. > > > > > > So either we save the process info, or we save the sighand, but saving the > > > "group_leader" seems totally bogus. Especially as the group leader can > > > change (by execve()). > > > > > > One thing that strikes me as I look at that function is that the whole > > > signalfd thing doesn't seem to do any reference counting. Ie it looks > > > totally buggy wrt passing the resulting fd off to somebody else, and then > > > exiting in the original process. > > > > > > What did I miss? > > > > Probably nothing... doesn't look good. What are the lifetime rules of a > > struct sighand tho ? > > Ah got it, signalfd_detach() in include/linux/signalfd.h from > exit_signal plus some rcu bits in signalfd lock/unlock. You could just get rid of the process/sighand/whatever reference entirely and just make reads on a signalfd always dequeue signals for the current thread. You'd lose the ability to pass signalfds around to other processes, but I'm not convinced that is even useful. (But I'm sure somebody smarter than me has a valid use case and would love to share :-) -- Nicholas Miell - 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/