Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ie0-f176.google.com ([209.85.223.176]:61091 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752144AbaCGX5I convert rfc822-to-8bit (ORCPT ); Fri, 7 Mar 2014 18:57:08 -0500 Received: by mail-ie0-f176.google.com with SMTP id rd18so5136542iec.21 for ; Fri, 07 Mar 2014 15:57:08 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored) From: Trond Myklebust In-Reply-To: <20140308104228.4bfcd3d5@notabene.brown> Date: Fri, 7 Mar 2014 18:57:03 -0500 Cc: Jim Rees , Dickson Steve , linux-nfs@vger.kernel.org Message-Id: <12C999A4-52B8-461F-BFB9-F67AB4F6EFCE@primarydata.com> References: <1394143352-26095-1-git-send-email-rees@umich.edu> <20140307185937.5852666b@notabene.brown> <20140308104228.4bfcd3d5@notabene.brown> To: Brown Neil Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mar 7, 2014, at 18:42, NeilBrown wrote: > On Fri, 7 Mar 2014 08:13:00 -0500 Trond Myklebust > wrote: > >> >> On Mar 7, 2014, at 2:59, NeilBrown wrote: >> >>> On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees wrote: >>> >>>> Signed-off-by: Jim Rees >>>> --- >>>> utils/mount/nfs.man | 53 ++++++----------------------------------------------- >>>> 1 file changed, 6 insertions(+), 47 deletions(-) >>>> >>>> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man >>>> index ef09a31..2ab369c 100644 >>>> --- a/utils/mount/nfs.man >>>> +++ b/utils/mount/nfs.man >>>> @@ -125,6 +125,12 @@ option may mitigate some of the risks of using the >>>> .B soft >>>> option. >>>> .TP 1.5i >>>> +.BR intr " / " nointr >>>> +This option is provided for backward compatibility. >>>> +It is ignored after kernel 2.6.25. >>>> +System calls return EINTR if an in-progress NFS operation is interrupted by >>>> +a signal. >>> >>> That isn't correct. >>> "A process that is waiting for a reply for an NFS server can be killed >>> by any signal which would normally kill the process. If a signal would not >>> normally kill the process (i.e. it is caught or ignored) then that signal >>> will not abort and NFS request". >>> >>> This is really a fairly horrible semantic. It makes perfect sense from an >>> internal implementation perspective and provides good backwards compatibility >>> and cross-compatibility with other filesystems (where 'read' and 'write' >>> never ever return EINTR), but it is very hard to document clearly. >>> >> Isn?t the documentation in the signal(7) manpage sufficient? We could simply refer to that? >> > > I would certainly be good if we could delegation the documentation. But I > couldn't find anything in signal(7) that seemed particularly relevant. Which > bit were you thinking of? > The table which lists the posix signals, and which indicates whether they are fatal not (i.e. what ?action? they cause). The same page also explains signal blocking and signal handling, which could also be helpful.. _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com