)]}'
{
  "commit": "d23c45fd84f79a3b84899dac053dcafe9d43ebc9",
  "tree": "38586e19ef996fdf12a11baf01ac3e62a9f56475",
  "parents": [
    "065015e5efff60884ad600a3e9a5127dbb684429"
  ],
  "author": {
    "name": "Chuck Lever",
    "email": "chuck.lever@oracle.com",
    "time": "Wed Jun 17 18:02:13 2009 -0700"
  },
  "committer": {
    "name": "Trond Myklebust",
    "email": "Trond.Myklebust@netapp.com",
    "time": "Wed Jun 17 18:02:13 2009 -0700"
  },
  "message": "NFS: Invalid mount option values should always fail, even with \"sloppy\"\n\nIan Kent reports:\n\n\"I\u0027ve noticed a couple of other regressions with the options vers\nand proto option of mount.nfs(8).\n\nThe commands:\n\nmount -t nfs -o vers\u003d\u003cinvalid version\u003e \u003cserver\u003e:/\u003cpath\u003e /\u003cmountpoint\u003e\nmount -t nfs -o proto\u003d\u003cinvalid proto\u003e \u003cserver\u003e:/\u003cpath\u003e /\u003cmountpoint\u003e\n\nboth immediately fail.\n\nBut if the \"-s\" option is also used they both succeed with the\nmount falling back to defaults (by the look of it).\n\nIn the past these failed even when the sloppy option was given, as\nI think they should. I believe the sloppy option is meant to allow\nthe mount command to still function for mount options (for example\nin shared autofs maps) that exist on other Unix implementations but\naren\u0027t present in the Linux mount.nfs(8). So, an invalid value\nspecified for a known mount option is different to an unknown mount\noption and should fail appropriately.\"\n\nSee RH bugzilla 486266.\n\nSigned-off-by: Chuck Lever \u003cchuck.lever@oracle.com\u003e\nSigned-off-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0b72357cdc41ce5ebfee0d6365b01fb1aa2996ec",
      "old_mode": 33188,
      "old_path": "fs/nfs/super.c",
      "new_id": "a2b2805caf9d998e55bfa453825236e87351d32b",
      "new_mode": 33188,
      "new_path": "fs/nfs/super.c"
    }
  ]
}