1. 24 Sep, 2009 1 commit
  2. 23 Sep, 2009 3 commits
  3. 21 Sep, 2009 1 commit
  4. 16 Sep, 2009 1 commit
  5. 08 Sep, 2009 5 commits
  6. 24 Aug, 2009 1 commit
    • Chuck Lever's avatar
      NFS: Handle a zero-length auth flavor list · 5eecfde6
      Chuck Lever authored
      
      
      Some releases of Linux rpc.mountd (nfs-utils 1.1.4 and later) return an
      empty auth flavor list if no sec= was specified for the export.  This is
      notably broken server behavior.
      
      The new auth flavor list checking added in a recent commit rejects this
      case.  The OpenSolaris client does too.
      
      The broken mountd implementation is already widely deployed.  To avoid
      a behavioral regression, the kernel's mount client skips flavor checking
      (ie reverts to the pre-2.6.32 behavior) if mountd returns an empty
      flavor list.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      5eecfde6
  7. 09 Aug, 2009 5 commits
  8. 23 Jun, 2009 2 commits
  9. 18 Jun, 2009 4 commits
    • Chuck Lever's avatar
      NFS: More "sloppy" parsing problems · a5a16bae
      Chuck Lever authored
      Specifying "port=-5" with the kernel's current mount option parser
      generates "unrecognized mount option".  If "sloppy" is set, this
      causes the mount to succeed and use the default values; the desired
      behavior is that, since this is a valid option with an invalid value,
      the mount should fail, even with "sloppy."
      
      To properly handle "sloppy" parsing, we need to distinguish between
      correct options with invalid values, and incorrect options.  We will
      need to parse integer values by hand, therefore, and not rely on
      match_token().
      
      For instance, these must all fail with "invalid value":
      
      	port=12345678
      	port=-5
      	port=samuel
      
      and not with "unrecognized option," as they do currently.
      
      Thus, for the sake of match_token() we need to treat the values for
      these options as strings, and do the conversion to integers using
      strict_strtol().
      
      This is basically the same solution we used for the earlier "retry="
      fix (commit ecbb3845
      
      ), except in this case the kernel actually has to
      parse the value, rather than ignore it.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      a5a16bae
    • Chuck Lever's avatar
      NFS: Invalid mount option values should always fail, even with "sloppy" · d23c45fd
      Chuck Lever authored
      
      
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d23c45fd
    • Chuck Lever's avatar
      NFS: Update MNT and MNT3 reply decoding functions · 8e02f6b9
      Chuck Lever authored
      
      
      Solder xdr_stream-based XDR decoding functions into the in-kernel mountd
      client that are more careful about checking data types and watching for
      buffer overflows.  The new MNT3 decoder includes support for auth-flavor
      list decoding.
      
      The "_sz" macro for MNT3 replies was missing the size of the file handle.
      I've added this back, and included the size of the auth flavor array.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      8e02f6b9
    • Chuck Lever's avatar
      NFS: Do not display the setting of the "intr" mount option · c381ad2c
      Chuck Lever authored
      
      
      The "intr" mount option has been deprecated for a while, but
      /proc/mounts continues to display "nointr" whether "intr" or "nointr"
      has been specified for a mount point.
      
      Since these options do not have any effect, simply do not display
      them.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      c381ad2c
  10. 17 Jun, 2009 4 commits
  11. 12 Jun, 2009 1 commit
  12. 09 May, 2009 2 commits
  13. 07 Apr, 2009 1 commit
  14. 03 Apr, 2009 3 commits
    • David Howells's avatar
      NFS: Add mount options to enable local caching on NFS · b797cac7
      David Howells authored
      
      
      Add NFS mount options to allow the local caching support to be enabled.
      
      The attached patch makes it possible for the NFS filesystem to be told to make
      use of the network filesystem local caching service (FS-Cache).
      
      To be able to use this, a recent nfsutils package is required.
      
      There are three variant NFS mount options that can be added to a mount command
      to control caching for a mount.  Only the last one specified takes effect:
      
       (*) Adding "fsc" will request caching.
      
       (*) Adding "fsc=<string>" will request caching and also specify a uniquifier.
      
       (*) Adding "nofsc" will disable caching.
      
      For example:
      
      	mount warthog:/ /a -o fsc
      
      The cache of a particular superblock (NFS FSID) will be shared between all
      mounts of that volume, provided they have the same connection parameters and
      are not marked 'nosharecache'.
      
      Where it is otherwise impossible to distinguish superblocks because all the
      parameters are identical, but the 'nosharecache' option is supplied, a
      uniquifying string must be supplied, else only the first mount will be
      permitted to use the cache.
      
      If there's a key collision, then the second mount will disable caching and give
      a warning into the kernel log.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSteve Dickson <steved@redhat.com>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarDaire Byrne <Daire.Byrne@framestore.com>
      b797cac7
    • David Howells's avatar
      NFS: Add some new I/O counters for FS-Cache doing things for NFS · 6a51091d
      David Howells authored
      
      
      Add some new NFS I/O counters for FS-Cache doing things for NFS.  A new line is
      emitted into /proc/pid/mountstats if caching is enabled that looks like:
      
      	fsc: <rok> <rfl> <wok> <wfl> <unc>
      
      Where <rok> is the number of pages read successfully from the cache, <rfl> is
      the number of failed page reads against the cache, <wok> is the number of
      successful page writes to the cache, <wfl> is the number of failed page writes
      to the cache, and <unc> is the number of NFS pages that have been disconnected
      from the cache.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSteve Dickson <steved@redhat.com>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarDaire Byrne <Daire.Byrne@framestore.com>
      6a51091d
    • David Howells's avatar
      NFS: Define and create superblock-level objects · 08734048
      David Howells authored
      
      
      Define and create superblock-level cache index objects (as managed by
      nfs_server structs).
      
      Each superblock object is created in a server level index object and is itself
      an index into which inode-level objects are inserted.
      
      Ideally there would be one superblock-level object per server, and the former
      would be folded into the latter; however, since the "nosharecache" option
      exists this isn't possible.
      
      The superblock object key is a sequence consisting of:
      
       (1) Certain superblock s_flags.
      
       (2) Various connection parameters that serve to distinguish superblocks for
           sget().
      
       (3) The volume FSID.
      
       (4) The security flavour.
      
       (5) The uniquifier length.
      
       (6) The uniquifier text.  This is normally an empty string, unless the fsc=xyz
           mount option was used to explicitly specify a uniquifier.
      
      The key blob is of variable length, depending on the length of (6).
      
      The superblock object is given no coherency data to carry in the auxiliary data
      permitted by the cache.  It is assumed that the superblock is always coherent.
      
      This patch also adds uniquification handling such that two otherwise identical
      superblocks, at least one of which is marked "nosharecache", won't end up
      trying to share the on-disk cache.  It will be possible to manually provide a
      uniquifier through a mount option with a later patch to avoid the error
      otherwise produced.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSteve Dickson <steved@redhat.com>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarDaire Byrne <Daire.Byrne@framestore.com>
      08734048
  15. 11 Mar, 2009 1 commit
  16. 23 Dec, 2008 4 commits
    • Trond Myklebust's avatar
      NFSv4: Clean up the support for returning multiple delegations · 515d8611
      Trond Myklebust authored
      
      
      Add a flag to mark delegations as requiring return, then run a garbage
      collector. In the future, this will allow for more flexible delegation
      management, where delegations may be marked for return if it turns out
      that they are not being referenced.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      515d8611
    • Chuck Lever's avatar
      NFS: "[no]resvport" mount option changes mountd client too · 50a737f8
      Chuck Lever authored
      
      
      If the admin has specified the "noresvport" option for an NFS mount
      point, the kernel's NFS client uses an unprivileged source port for
      the main NFS transport.  The kernel's mountd client should use an
      unprivileged port in this case as well.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      50a737f8
    • Chuck Lever's avatar
      NFS: add "[no]resvport" mount option · d740351b
      Chuck Lever authored
      
      
      The standard default security setting for NFS is AUTH_SYS.  An NFS
      client connects to NFS servers via a privileged source port and a
      fixed standard destination port (2049).  The client sends raw uid and
      gid numbers to identify users making NFS requests, and the server
      assumes an appropriate authority on the client has vetted these
      values because the source port is privileged.
      
      On Linux, by default in-kernel RPC services use a privileged port in
      the range between 650 and 1023 to avoid using source ports of well-
      known IP services.  Using such a small range limits the number of NFS
      mount points and the number of unique NFS servers to which a client
      can connect concurrently.
      
      An NFS client can use unprivileged source ports to expand the range of
      source port numbers, allowing more concurrent server connections and
      more NFS mount points.  Servers must explicitly allow NFS connections
      from unprivileged ports for this to work.
      
      In the past, bumping the value of the sunrpc.max_resvport sysctl on
      the client would permit the NFS client to use unprivileged ports.
      Bumping this setting also changes the maximum port number used by
      other in-kernel RPC services, some of which still required a port
      number less than 1023.
      
      This is exacerbated by the way source port numbers are chosen by the
      Linux RPC client, which starts at the top of the range and works
      downwards.  It means that bumping the maximum means all RPC services
      requesting a source port will likely get an unprivileged port instead
      of a privileged one.
      
      Changing this setting effects all NFS mount points on a client.  A
      sysadmin could not selectively choose which mount points would use
      non-privileged ports and which could not.
      
      Lastly, this mechanism of expanding the limit on the number of NFS
      mount points was entirely undocumented.
      
      To address the need for the NFS client to use a large range of source
      ports without interfering with the activity of other in-kernel RPC
      services, we introduce a new NFS mount option.  This option explicitly
      tells only the NFS client to use a non-privileged source port when
      communicating with the NFS server for one specific mount point.
      
      This new mount option is called "resvport," like the similar NFS mount
      option on FreeBSD and Mac OS X.  A sister patch for nfs-utils will be
      submitted that documents this new option in nfs(5).
      
      The default setting for this new mount option requires the NFS client
      to use a privileged port, as before.  Explicitly specifying the
      "noresvport" mount option allows the NFS client to use an unprivileged
      source port for this mount point when connecting to the NFS server
      port.
      
      This mount option is supported only for text-based NFS mounts.
      
      [ Sidebar: it is widely known that security mechanisms based on the
        use of privileged source ports are ineffective.  However, the NFS
        client can combine the use of unprivileged ports with the use of
        secure authentication mechanisms, such as Kerberos.  This allows a
        large number of connections and mount points while ensuring a useful
        level of security.
      
        Eventually we may change the default setting for this option
        depending on the security flavor used for the mount.  For example,
        if the mount is using only AUTH_SYS, then the default setting will
        be "resvport;" if the mount is using a strong security flavor such
        as krb5, the default setting will be "noresvport." ]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      [Trond.Myklebust@netapp.com: Fixed a bug whereby nfs4_init_client()
      was being called with incorrect arguments.]
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d740351b
    • Chuck Lever's avatar
      NFS: introduce nfs_mount_info struct for calling nfs_mount() · c5d120f8
      Chuck Lever authored
      
      
      Clean up: convert nfs_mount() to take a single data structure argument to make
      it simpler to add more arguments.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      c5d120f8
  17. 31 Oct, 2008 1 commit