NFS: Invalid mount option values should always fail, even with "sloppy"
authorChuck Lever <chuck.lever@oracle.com>
Thu, 18 Jun 2009 01:02:13 +0000 (18:02 -0700)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Thu, 18 Jun 2009 01:02:13 +0000 (18:02 -0700)
commitd23c45fd84f79a3b84899dac053dcafe9d43ebc9
tree38586e19ef996fdf12a11baf01ac3e62a9f56475
parent065015e5efff60884ad600a3e9a5127dbb684429
NFS: Invalid mount option values should always fail, even with "sloppy"

Ian Kent reports:

"I've noticed a couple of other regressions with the options vers
and proto option of mount.nfs(8).

The commands:

mount -t nfs -o vers=<invalid version> <server>:/<path> /<mountpoint>
mount -t nfs -o proto=<invalid proto> <server>:/<path> /<mountpoint>

both immediately fail.

But if the "-s" option is also used they both succeed with the
mount falling back to defaults (by the look of it).

In the past these failed even when the sloppy option was given, as
I think they should. I believe the sloppy option is meant to allow
the mount command to still function for mount options (for example
in shared autofs maps) that exist on other Unix implementations but
aren't present in the Linux mount.nfs(8). So, an invalid value
specified for a known mount option is different to an unknown mount
option and should fail appropriately."

See RH bugzilla 486266.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fs/nfs/super.c