Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Trond Myklebust <trondmy@hammerspace.com>
To:     "neilb@suse.de" <neilb@suse.de>,
        "anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support
 NFS4_OPEN_CLAIM_DELEG_CUR_FH
Thread-Topic: [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support
 NFS4_OPEN_CLAIM_DELEG_CUR_FH
Thread-Index: AQHVtfUj0Db4D3dPKk6JV7ObGp2xVqfAjyIA
Date:   Wed, 18 Dec 2019 23:47:43 +0000
Message-ID: <3afd2d5c631d8e3429e025e204a7b1c95b3c1415.camel@hammerspace.com>
References: <87y2v9fdz8.fsf@notabene.neil.brown.name>
In-Reply-To: <87y2v9fdz8.fsf@notabene.neil.brown.name>
Accept-Language: en-US, en-GB
Content-Language: en-US
received-spf: None (protection.outlook.com: hammerspace.com does not designate
 permitted sender hosts)
Content-Type: multipart/signed; micalg="pgp-sha256";
        protocol="application/pgp-signature"; boundary="=-FyTE+QCSNs79Sxx6UWsa"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 93f99644-cfce-4512-1415-08d78414ad21
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 23:47:43.3144
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0d4fed5c-3a70-46fe-9430-ece41741f59e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 174x3vtZqThXKZ+U0joBKTukrf+IHchfrEziDY15t6sZvwHMKq4vsk25E6iTb8qp4FhSqfRlofGgQCFzSgPatg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1301MB1929
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

--=-FyTE+QCSNs79Sxx6UWsa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2019-12-19 at 09:47 +1100, NeilBrown wrote:
> If an NFSv4.1 server doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH
> (e.g. Linux 3.0), and a newer NFS client tries to use it to claim
> an open before returning a delegation, the server might return
> NFS4ERR_BADXDR.
> That is what Linux 3.0 does, though the RFC doesn't seem to be
> explicit
> on which flags must be supported, and what error can be returned for
> unsupported flags.

NFS4ERR_BADXDR is defined in RFC5661, section 15.1.1.1 as meaning

"The arguments for this operation do not match those specified in the
XDR definition."

That's clearly not the case here, so I'd chalk this down to a fairly
blatant server bug, at which point it makes no sense to fix it in the
client.

--=20
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com


--=-FyTE+QCSNs79Sxx6UWsa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESQctxSBg8JpV8KqEZwvnipYKAPIFAl36upgACgkQZwvnipYK
APKt0A/5AaVLeXvi7ltKDZ+sKHsXZv2fno0Fk5DBf9FDLmIMdx9xnmRj3YX0E5Qa
Fy2uC6MNf0YwzxMVnAV/Dpyy4Nxl8yIgKh9upPsyf6ZufAP+aN3GAvdcogqzdFRY
X4odqR8EGIJ3Cw1EA2UaFNELjbJLM4x1ONDGxSw4lkmw/rVBX3giDwxjkHL7O2dr
v5AItIje2nb1ob65FU55daY8Eqhqmxhj4T8acGKKWHGZbseeTfAIpLTyw/pkIque
VAmdYTT7NZX70npQmgjc3fjMrpxlvsXZFZpKULPs3m5JOyl+KpAE6daB+SmUShY5
mGlEArAsPDP9EBIchMnTDNSSZSvmCqYpyOjzkQL/zf6+MqumJO6Wb6oWu8yKGN3x
5S+jCV2epls17gQCT3GYou6VoIWOm1MndCJlnHCaIDBQ8G8D3ajojk09qiOl6cIy
ny3/8ZhbdhTf7n0J0dVncqWxCoyWgs26MSa/xca0YCw5joORNwG74pHkR753jtsH
takwAYQ784Q4RFLZfw4H1YXXg6NElsOnoL1vY1b0EKkqh/MI0bNgg31awS4g5l3s
Sfw7UPj5z0jJdCwW3RVQ2tZ2AtzYKAx72OOHkbEALHjNAC/MKz1H1LJ1JCuCWTJq
sLgsmKD6wkCjGOB30NAnA/Hc83OtEK/vsResbdKukgINUzaRVwk=
=7YZU
-----END PGP SIGNATURE-----

--=-FyTE+QCSNs79Sxx6UWsa--