All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Jim Rees <rees@umich.edu>, Dickson Steve <steved@redhat.com>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)
Date: Sat, 8 Mar 2014 10:42:28 +1100	[thread overview]
Message-ID: <20140308104228.4bfcd3d5@notabene.brown> (raw)
In-Reply-To: <D65A0AA5-ADF9-43AA-871F-69533C8F2DD7@primarydata.com>

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Fri, 7 Mar 2014 08:13:00 -0500 Trond Myklebust
<trond.myklebust@primarydata.com> wrote:

> 
> On Mar 7, 2014, at 2:59, NeilBrown <neilb@suse.de> wrote:
> 
> > On Thu,  6 Mar 2014 17:02:32 -0500 Jim Rees <rees@umich.edu> wrote:
> > 
> >> Signed-off-by: Jim Rees <rees@umich.edu>
> >> ---
> >> 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?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2014-03-07 23:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06 22:02 [PATCH] fix intr/nointr to match kernel behavior (ignored) Jim Rees
2014-03-07  7:59 ` NeilBrown
2014-03-07 13:13   ` Trond Myklebust
2014-03-07 23:42     ` NeilBrown [this message]
2014-03-07 23:57       ` Trond Myklebust
2014-03-08  1:38         ` Jim Rees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140308104228.4bfcd3d5@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    --cc=steved@redhat.com \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.