From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: filesystem signal handling Date: Thu, 29 Apr 2004 07:41:59 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1083220919.4694.59.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> <1083172459.4694.27.camel@localhost.localdomain> <1083173539.2856.90.camel@lade.trondhjem.org> <20040428192835.GA2836@mail.shareable.org> <1083205102.4694.39.camel@localhost.localdomain> <1083207196.2856.220.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , Steve French , linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.86.99.235]:45543 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S263616AbUD2GmV (ORCPT ); Thu, 29 Apr 2004 02:42:21 -0400 To: Trond Myklebust In-Reply-To: <1083207196.2856.220.camel@lade.trondhjem.org> List-Id: linux-fsdevel.vger.kernel.org On Wed, 2004-04-28 at 22:53 -0400, Trond Myklebust wrote: > One of the main points of playing with the sigmask in the first place is > that interrupting an operation in the middle of the RPC call leaves > various attribute/data caches in an incoherent state, and so is in > general bad practice. We can generalise that. The main reason for blocking signals -- be it by using TASK_UNINTERRUPTIBLE, manipulating the sigmask, or some hypothetical 'uninterruptible_count' in the task_struct, is that in some places we either can't or don't want to clean up properly if a signal happens. Sometimes that requirement comes all the way from userspace (e.g. expected semantics of sys_read() and short reads) In those problematic cases, we often call other functions which may sleep any may potentially be interrupted -- since we can't handle that, we obviously require them _not_ to be interrupted. But making those functions use TASK_UNINTERRUPTIBLE means that they can't be interrupted even when called by other callers which _could_ clean up after themselves -- unless we do something horrid like passing a flag all the way down to say what sleep state should be used. The advantage of doing it with the latter two methods mentioned above is that the 'problematic' routine can make that decision for itself and set some state, and then the routines which it calls don't need to care. They just _don't_ get interrupted when they're called from a function which cannot handle receiving -EINTR. > We certainly don't want something like a poorly > coded application that generates the occasional SIGSEGV or SIGBUS (or > even a well-coded one that uses timers + SIGALRM!) to screw up the > cached data/metadata for everyone else. If that's a possible outcome, why doesn't that happen with uncaught SIGINT? -- dwmw2