From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: filesystem signal handling Date: Wed, 28 Apr 2004 20:47:14 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040428194714.GA2982@mail.shareable.org> 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> <1083181437.2856.109.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Woodhouse , Steve French , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:13952 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S261615AbUD1TrV (ORCPT ); Wed, 28 Apr 2004 15:47:21 -0400 To: Trond Myklebust Content-Disposition: inline In-Reply-To: <1083181437.2856.109.camel@lade.trondhjem.org> List-Id: linux-fsdevel.vger.kernel.org Trond Myklebust wrote: > I must admit that I'm unclear as to the full reason why we do that, but > I guess that at least part of the problem is that we're not going to be > reentrant if the handler decides to ignore the signal. Eh? When a signal is handled, that is done by aborting the current kernel operation (e.g. read), returning to userspace, letting userspace handle the signal, and then possibly restarting the aborted operation by doing the system call again. How does re-entrancy come into it? -- Jamie