diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2009-06-17 18:02:13 -0700 |
---|---|---|
committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2009-06-17 18:02:13 -0700 |
commit | d23c45fd84f79a3b84899dac053dcafe9d43ebc9 (patch) | |
tree | 38586e19ef996fdf12a11baf01ac3e62a9f56475 /fs/ecryptfs/keystore.c | |
parent | 065015e5efff60884ad600a3e9a5127dbb684429 (diff) | |
download | linux-d23c45fd84f79a3b84899dac053dcafe9d43ebc9.tar.bz2 |
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>
Diffstat (limited to 'fs/ecryptfs/keystore.c')
0 files changed, 0 insertions, 0 deletions