Mount regression between 4.0.4 client and 2.6.35 server

PATCH Anders Blomdell 5 participants 9 messages Jun 18, 2015 – Jun 26, 2015

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Anders Blomdell

author

2015-06-18 08:23 UTC #0 lore raw

I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.

Proposed patch attached.

Regards

Anders Blomdell

Signature · 5 lines

Anders Blomdell                  Email: [email protected]
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Minimum viable patch to continue version autonegotiotion in case where the server returns an unexpected NFS4ERR_INVAL, which happens for a 4.0.4-303.fc22.x86_64 client talking to a 2.6.35.14-106.fc14.i686.PAE server, see
https://bugzilla.redhat.com/show_bug.cgi?id=1228272

Signed-off-by Anders Blomdell <[email protected]>

mount/stropts.c renamed from mount/stropts.c.orig +4 -0

@@ -838,6 +838,10 @@ check_result:
 		return result;
 
 	switch (errno) {
+	case EIO:
+		/* Fix to handle nfs4_discover_server_trunking returning
+		 * EIO in case where nfs server returns NFS4ERR_INVAL,
+		 * see https://bugzilla.redhat.com/show_bug.cgi?id=1228272 */
 	case EPROTONOSUPPORT:
 		/* A clear indication that the server or our
 		 * client does not support NFS version 4 and minor */

Trond Myklebust

2015-06-18 11:49 UTC #1 lore raw

Quoted 4 lines · Anders Blomdell

I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.

Why should we change the clients if the server is in clear and obvious violation of the spec?

Cheers
Trond

Anders Blomdell

author

2015-06-18 12:28 UTC #2 lore raw

Quoted 10 lines · Trond Myklebust

Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Why should we change the clients if the server is in clear and obvious violation of the spec?

In order to make clients work with servers that worked well with previous versions of nfs-utils, the cultprit probably being commit f9802988 that bumped the default autonegotion version to 4.2, what the patch does is only to negotiate a lower version in case of errors, and hence making 1.3.2 working with servers that worked with 1.3.1 (that only tried version 4[.0]).

Will probably save some people some time.

/Anders

Signature · 5 lines

Anders Blomdell                  Email: [email protected]
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Trond Myklebust

2015-06-18 12:53 UTC #3 lore raw

Quoted 11 lines · Anders Blomdell

Quoted 10 lines · Trond Myklebust
Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Why should we change the clients if the server is in clear and obvious violation of the spec?

Quoted 7 lines

In order to make clients work with servers that worked well with previous versions of nfs-utils, the cultprit probably being commit f9802988 that bumped the default autonegotion version to 4.2, what the patch does is only to negotiate a lower version in case of errors, and hence making 1.3.2 working with servers that worked with 1.3.1 (that only tried version 4[.0]).
Will probably save some people some time.

This is what /etc/nfsmount.conf is for. We don't fix clients that are working correctly according to the protocol spec.

Trond

Steve Dickson

2015-06-18 14:20 UTC #4 lore raw

Hello,

BTW, I asked Anders to post this patch to
get this discussion going.

Quoted 19 lines · Trond Myklebust

Quoted 17 lines · Anders Blomdell
Quoted 10 lines · Trond Myklebust
Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Why should we change the clients if the server is in clear and obvious violation of the spec?
In order to make clients work with servers that worked well with previous versions of nfs-utils, the cultprit probably being commit f9802988 that bumped the default autonegotion version to 4.2, what the patch does is only to negotiate a lower version in case of errors, and hence making 1.3.2 working with servers that worked with 1.3.1 (that only tried version 4[.0]).

Quoted 5 lines

Quoted 1 line
Will probably save some people some time.
This is what /etc/nfsmount.conf is for. We don't fix clients that are working correctly according to the protocol spec.

Using /etc/nfsmount.conf does not scale very well when there is a large number clients involved...

When we bumped up the auto-negotiation to 4.2, I thinking there would be issues with legacy servers. But I was thinking obscure servers like AIX would break, not old Linux servers and possibly Solaris servers (I'm trying to check that now)

Inlining the patch:

mount/stropts.c renamed from mount/stropts.c.orig +4 -0

@@ -838,6 +838,10 @@ check_result:
 		return result;
 
 	switch (errno) {
+	case EIO:
+		/* Fix to handle nfs4_discover_server_trunking returning
+		 * EIO in case where nfs server returns NFS4ERR_INVAL,
+		 * see https://bugzilla.redhat.com/show_bug.cgi?id=1228272 */
 	case EPROTONOSUPPORT:
 		/* A clear indication that the server or our
 		 * client does not support NFS version 4 and minor */

Now I'm not sure this is the right to handle this but I do think it is a good idea to make the auto-negation mounting code smarter to handle these legacy servers.

steved.

Benjamin Coddington

2015-06-26 12:17 UTC #5 lore raw

In reply to Trond Myklebust

Quoted 10 lines · Trond Myklebust

Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Why should we change the clients if the server is in clear and obvious violation of the spec?

What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the request.

Should the client's use of stateid/princ binding be optional/configureable?

Ben

J. Bruce Fields

2015-06-26 17:50 UTC #6 lore raw

Quoted 10 lines · Benjamin Coddington

Quoted 8 lines · Trond Myklebust
Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.

Quoted 7 lines

Quoted 2 lines
Why should we change the clients if the server is in clear and obvious violation of the spec?
What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the request.

Note that intentionally left off by default until 3.11, exactly because I thought there was a high risk of incompatibility with future clients at that point.

Quoted 1 line

Should the client's use of stateid/princ binding be optional/configureable?

So, perhaps there's other reasons for doing this, but we're not going to justify it for compatibility with out-of-spec behavior in older experimental server code.

Possibly more annoying is that Solaris servers (I don't know which versions, I just have one report that says "Solaris 10") are also returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on attempts to use 4.2.

--b.

Trond Myklebust

2015-06-26 17:58 UTC #7 lore raw

Quoted 23 lines · J. Bruce Fields

Quoted 10 lines · Benjamin Coddington
Quoted 8 lines · Trond Myklebust
Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Quoted 7 lines
Quoted 2 lines
Why should we change the clients if the server is in clear and obvious violation of the spec?
What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the request.
Note that intentionally left off by default until 3.11, exactly because I thought there was a high risk of incompatibility with future clients at that point.

Quoted 5 lines

Quoted 1 line
Should the client's use of stateid/princ binding be optional/configureable?
So, perhaps there's other reasons for doing this, but we're not going to justify it for compatibility with out-of-spec behavior in older experimental server code.

The protocol gives the server the option of rejecting the client's request for bind_princ_stateid by simply turning off the flag in its reply. See https://tools.ietf.org/html/rfc5661#section-18.35.3

Quoted 4 lines

Possibly more annoying is that Solaris servers (I don't know which versions, I just have one report that says "Solaris 10") are also returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on attempts to use 4.2.

J. Bruce Fields

2015-06-26 18:32 UTC #8 lore raw

Quoted 26 lines · Trond Myklebust

Quoted 25 lines · J. Bruce Fields
Quoted 10 lines · Benjamin Coddington
Quoted 8 lines · Trond Myklebust
Quoted 4 lines · Anders Blomdell
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Quoted 7 lines
Quoted 2 lines
Why should we change the clients if the server is in clear and obvious violation of the spec?
What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the request.
Note that intentionally left off by default until 3.11, exactly because I thought there was a high risk of incompatibility with future clients at that point.
Quoted 1 line
Should the client's use of stateid/princ binding be optional/configureable?

Quoted 7 lines

Quoted 3 lines
So, perhaps there's other reasons for doing this, but we're not going to justify it for compatibility with out-of-spec behavior in older experimental server code.
The protocol gives the server the option of rejecting the client's request for bind_princ_stateid by simply turning off the flag in its reply. See https://tools.ietf.org/html/rfc5661#section-18.35.3

Yeah, that's what it's doing.

(The failure in this case was because the code just didn't know about the flag at all--I think it still had constants taken from an earlier ietf draft. Like I say, experimental code.)

--b.

Quoted 5 lines

Quoted 5 lines
Possibly more annoying is that Solaris servers (I don't know which versions, I just have one report that says "Solaris 10") are also returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on attempts to use 4.2.