From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: filesystem signal handling Date: Wed, 28 Apr 2004 18:14:19 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1083172459.4694.27.camel@localhost.localdomain> References: <1083097744.4780.20.camel@stevef95.austin.ibm.com> <1083165278.4694.12.camel@localhost.localdomain> <1083171946.2856.63.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Steve French , linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.86.99.235]:11744 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S264985AbUD1ROc (ORCPT ); Wed, 28 Apr 2004 13:14:32 -0400 To: Trond Myklebust In-Reply-To: <1083171946.2856.63.camel@lade.trondhjem.org> List-Id: linux-fsdevel.vger.kernel.org On Wed, 2004-04-28 at 13:05 -0400, Trond Myklebust wrote: > On Wed, 2004-04-28 at 11:14, David Woodhouse wrote: > > > NFS does this. It's fairly ugly. What would be a _lot_ nicer if we could > > have something in the task_struct which is vaguely reminiscent of > > preempt_count, only it counts the number of reasons why this task cannot > > receive signals. So instead of using the TASK_INTERRUPTIBLE and > > TASK_UNINTERRUPTIBLE states to make the decision, we'd look at the > > task's uninterruptible_count instead. > > The reason NFS has the scheme that it does is precisely *because* we > want to set our own sigmask. > > The reason is that we'd like to respect SIGINT, SIGQUIT and SIGKILL as > signalling that the user wants to interrupt the operation if and only if > the "intr" mount flag has been set. Is there a benefit to having precisely this implementation, as opposed to the option of allowing only fatal signals? What standard do we need to adhere to? -- dwmw2