summaryrefslogtreecommitdiffstats
path: root/mm/rmap.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2009-06-17 18:02:13 -0700
committerTrond Myklebust <Trond.Myklebust@netapp.com>2009-06-17 18:02:13 -0700
commitd23c45fd84f79a3b84899dac053dcafe9d43ebc9 (patch)
tree38586e19ef996fdf12a11baf01ac3e62a9f56475 /mm/rmap.c
parent065015e5efff60884ad600a3e9a5127dbb684429 (diff)
downloadlinux-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 'mm/rmap.c')
0 files changed, 0 insertions, 0 deletions