From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: filesystem signal handling Date: Wed, 28 Apr 2004 16:14:38 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1083165278.4694.12.camel@localhost.localdomain> References: <1083097744.4780.20.camel@stevef95.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.86.99.235]:59614 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S264849AbUD1POs (ORCPT ); Wed, 28 Apr 2004 11:14:48 -0400 To: Steve French In-Reply-To: <1083097744.4780.20.camel@stevef95.austin.ibm.com> List-Id: linux-fsdevel.vger.kernel.org On Tue, 2004-04-27 at 15:29 -0500, Steve French wrote: > I noticed that the ramfs and libfs code do not have special handling of > signals (checking for signal_pending, returning or handling ERESTARTSYS > or EINTR). > > Is it permitted for a filesystem to mask signals temporarily across most > fs calls and simply let the higher layers handle checking for > signal_pending (other than using the existing of a signal_pending to > shorten schedule_timeouts so the app would not wait as long on errors)? 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. That way, we can provide functions, including the ones you mention as dangerous, which do the right thing _both_ when called from a function which cannot tolerate signals, and when called from a function which _can_ perform the necessary cleanup. Without screwing with the signal masks. (In fact, I think it would be useful also to have a way of saying that _fatal_ signals should be allowed, but not signals with a handler. This would be useful in, e.g., sys_read() and sys_write().) -- dwmw2