All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH - v2] NFSv4: handle EINVAL from EXCHANGE_ID better.
Date: Tue, 3 Apr 2018 12:02:58 -0400	[thread overview]
Message-ID: <20180403160258.GC20297@fieldses.org> (raw)
In-Reply-To: <87bmf115pn.fsf@notabene.neil.brown.name>

On Tue, Apr 03, 2018 at 10:41:56AM +1000, NeilBrown wrote:
> On Tue, Mar 20 2018, J. Bruce Fields wrote:
> 
> > On Fri, Mar 16, 2018 at 10:44:23AM +1100, NeilBrown wrote:
> >> 
> >> nfs4_proc_exchange_id() can return -EINVAL if the server
> >> reported NFS4INVAL (which I have seen in a packet trace),
> >
> > Can you say which server this was?  (One we can fix?)
> 
> It was Linux 2.6.32 (on armv5), and presumably anything before
> Commit: 357f54d6b382 ("NFS fix the setting of exchange id flag")
> which landed in 2.6.38.

The kernel defaulted to keeping 4.1 off at that point, probably for good
reason--that default didn't change for another 4 or 5 years.  I suspect
this is only the first of multiple 4.1 bugs you'd run into in a server
of that vintage.  So the solution is probably just to keep 4.1 off.

--b.

> 
> These servers return NFS4ERR_INVAL when EXCHGID4_FLAG_BIND_PRINC_STATEID
> is set in the exchange_id flags, which Linux has done since
> Commit: 4f0b429df104 ("NFSv4.1: Enable state protection")
> in 3.11.
> 
> Maybe NFS should retry without that flag if it gets EINVAL??  Or it could
> just say that NFSv4.1 isn't supported.  I still don't think EIO is justified.
> 
> Thanks,
> NeilBrown



      reply	other threads:[~2018-04-03 16:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 23:29 [PATCH] NFSv4: handle EINVAL from EXCHANGE_ID better NeilBrown
2018-03-15 23:44 ` [PATCH - v2] " NeilBrown
2018-03-16  9:31   ` Mkrtchyan, Tigran
2018-03-16 12:10     ` Trond Myklebust
2018-03-20  0:32       ` NeilBrown
2018-03-20 14:14         ` Trond Myklebust
2018-03-20 18:44           ` NeilBrown
2018-03-20 19:43             ` Trond Myklebust
2018-03-20 19:58               ` NeilBrown
2018-03-20 20:13                 ` Trond Myklebust
2018-03-20 21:20                   ` NeilBrown
2018-03-20  0:09     ` NeilBrown
2018-03-20 21:48   ` J. Bruce Fields
2018-03-20 22:12     ` NeilBrown
2018-04-03  0:41     ` NeilBrown
2018-04-03 16:02       ` J. Bruce Fields [this message]

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=20180403160258.GC20297@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.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.